The update itself was quick to download, taking only about a minute. Surprisingly, after that I had to wait another five minutes, just staring at “Preparing Update…” After that I received an alert stating “your device must be charged at least 50% or connected to a power source to continue upgrading.” Without asking, I grabbed a charger off my coworker’s desk (thanks, Andy). The traditional install screen popped up and I felt myself getting jitterier by the minute.

Update complete, my first goal was to add all the credit/debit cards in my wallet into Passbook, where Apple Pay stores your cards. Not totally surprisingly, only one of the four cards was accepted. The other three (Simple, Barclays, and U.S. Bank) were all rejected with an error of “Your Issuer Does Not Yet Offer Support for This Card.” I found the lack of support from Barclays interesting, as Apple uses them for financing and credit.

However, I was able to activate my Chase debit card. Scanning it with the iPhone 6 camera was completely painless — the only field I had to manually enter was the three-digit pin code on the back.

After uploading my card, I had the option of having a verification code texted, emailed or phoned to me.  This information appears to have been pulled from Chase’s system, as it differs from the information I use on my phone and with iCloud. I decided on a text, and didn’t even need to switch apps as Notification Center showed my code at the top of the screen while I entered it. Once everything was validated and confirmed with Chase, I was brought back to Passbook and shown a simplified version of my debit card.

With my card entered into the system, I trekked over to Kowalski’s in Uptown for lunch. They’re not a verified Apple merchant, but I knew they had new NFC-enabled purchase terminals. After grabbing a turkey sandwich, I made my way to the cash register and prepared myself. *Beep* sandwich swiped, time to pay. As I pressed my phone against the NFC sensor, the cashier gave me an interesting look. Somewhere between confusion and “Is this guy an idiot….?”

My iPhone displayed a greyed-out fingerprint logo, similar to the one presented when setting up Touch ID on an iPhone 5s or higher.  I pressed my thumb on the home button and the lines started swirling around and began to fill in with white. It didn’t outright say it, but the animation gave off a “please wait, scanning” vibe. About one second later, the fingerprint logo was replaced with a pleasing checkmark, and the cashier’s monitor flashed ACCEPTED in big bold letters. I couldn’t tell if the cashier’s confusion grew or subsided from this, but she handed me my lunch and I was on my way.

Overall, the process was quick and (contrary to my title) a little underwhelming. Which is probably a good thing. Purchases shouldn’t be complex and intricate procedures; they’re SUPPOSED to be quick and easy.  I was also happy to see Apple Pay work with a small merchant that had an NFC-capable checkout system. Now that I have that first purchase under my belt, I’m excited to continue using Apple Pay as more banks become supported and additional merchants begin offering NFC transactions.

The post Apple Pay: You’ll never forget your first time appeared first on Software for Good.

I’ve been a registered iOS developer for several years now and an OS X dev for about a year. One of the perks of being a developer is being granted beta access to software before it’s fully released to the public. Beta software, however, is usually riddled with bugs. As it turns out, many of my heavily used applications are not compatible with iOS 8.

Immediately after updating my phone, I proceeded to install OS X 10.10 Yosemite on my MacBook Pro. All appeared to be going well until it hung on “5 minutes remaining” for nearly three hours. As is the standard step one for any tech project, I restarted it and tried again to see if it would fix the solution. Sadly, it did not, and I was left with a non-booting laptop.

Thankfully, I have backups, and plenty of them. Until recently, I used Dropbox to store all of my photos and PDF files, though I’m slowly migrating all of that over to ownCloud. I have a 500GB drive attached to my home-office dock that runs hourly TimeMachine backups. I also back up remotely to CrashPlan, ensuring the ability to do a full data recovery in the event of a house fire or some other catastrophic event. My home servers also back up to CrashPlan, and all of my iDevices back up to iCloud.

Backups go beyond data, though. Being a software developer in 2014 means that having access to the Internet is quite important. I can’t get updated code from my peers, deploy a staging site, or respond to emails with funny GIFs without a connection. I have Comcast Internet at home, but I also have the ability to tether off my phone or use a 4G hotspot in case that connection drops. If my motorcycle fails to start, I can take my car into work. If my laptop were to die a horrific death, I could use my iPad with a Bluetooth keyboard to SSH into a remote server and code. One of the the major upsides to coding with vi(m) is that it’s installed on almost every *NIX distro, but that’s a conversation for another day.

At Software for Good, we follow even more rigorous backup policies. Our code is automatically backed up to GitHub as part of our programming workflow. Production Postgres and MySQL databases are backed up every 6 hours, and virtual servers are typically on a 7-day rolling backup schedule. Design files are backed up with BitSync, allowing designers to simultaneously back up files and share them with front-end developers. While each project has a lead developer, that person is rarely the only developer on a project.

In the software development world, there is a concept known as “bus factor.” In short, the bus factor is the number of people who would need to be killed by a bus in order to stop the project dead in its tracks. Sounds morbid, and it is, but it serves a good purpose. If you only have one developer working on a project and then that one dev is no longer available, you now have to do a complete ramp-up of a new developer with almost no knowledge about the project’s current state. To combat this, we usually have second developers check in on projects once or twice a week, just to get a feel of where things are at, be brought up to speed on current issues, and double-check any critical decisions made. While some clients may balk at this, as it is a slight increase in development cost, the long-term gains strongly outweigh the short-term costs. No matter what it is, we make sure to back it up, not only because it’s important to us, but because it’s also important to our clients.

Right now my MacBook Pro is restoring from a TimeMachine backup created last night at 11:42pm. It is estimating to take ~4 hours to complete, though if that ends up being true, it’s far shorter than it would have taken me to set up my machine from scratch.

The post Backups appeared first on Software for Good.

Most of the points in this post can be applied to any field. I am just focusing on software development because that’s what I know.

I hear time and time again that finding the right people for a tech company is borderline impossible. That is a complete lie, though I’ll agree that using “traditional” methods of hiring doesn’t work too often with developers.

Finding Good Talent

Step number one: stop relying on job boards. If you’re going to use them, at least use developer-focused boards like Stack Overflow’s Careers. And did you know that there are places where developers actually group together, many of them potentially interested in new jobs? They’re called user groups, and they are usually very open to companies coming in and saying, “Hi, we’re Company X, and we’re looking for one senior Y developer.” If you’re local to the Twin Cities and looking for a Rails developer, you would probably have great luck stopping by one of the Ruby.mn meetings.

Step two is getting rid of recruiters. I can’t even count how many times I’ve spoken to a recruiter who knows nothing about development: “I am helping a Fortune 500 company find a senior developer! It appears you have an extensive background in PHP, so I think you would be a great fit for their Cold Fusion position!” At best these people only slightly irritate me. At worst, they make me promise myself to never work with whatever company they’re hiring for. If you already have a few developers working with you, offer a small cash bonus if they find additional talent. They’ll be able to more accurately judge the skill sets of other developers, and you potentially save money. (I’ve seen how expensive recruiters can be.)

Developer-Friendly Environments

There’s also the challenge of making your office/workspace/command center developer-friendly. Currently the number of developer jobs far outweighs the number of good developers, so someone with a lot of talent can afford to be picky about where he/she ends up.

I’ve worked at past jobs where they care more about your rear being in a seat from 9-5 than the quality of the code you produce. If you focus on someone’s rear, you’ll get a wonderful 40 hours a week of sitting, but you’re not necessarily going to get good code.

Development is an art form. This is why a developer will often grab a cup of coffee and just sit thinking for a while in the morning. “The code I’m going to write today… I’ll need to make sure I account for 418 status codes. Oh yeah, I’ll also have to make sure the user can upload multiple files instead of just one at a time.” Code is often written and rewritten several times in a developer’s head before it gets typed out into a file. Sometimes the proverbial lightbulb comes on at 7:30pm, after a nice dinner accompanied by a milk stout. If you demand that your developers work from 9-5, at 5:01pm they will be officially checked out. If instead you allow some fluidity in a developer’s work schedule, they are much more likely to take that evening idea, jump back on their computer, and produce quality code.

That’s not to say that you should allow 20 hour week works or accept people to work only 2 hours a day. I am simply advocating that a company be flexible with its ‘when’ and ‘where’ of the code writing. If your response is, “I can’t trust my employees to work when they are outside of the office,” then I ask: If you don’t trust them to do their job unsupervised, why did you hire them in the first place?

On a somewhat related note, arm developers with tools to help them succeed. If you give a developer a desktop, it keeps him/her physically stationary. “But you can work on any computer!” is something a non-developer would say. That’s like saying a mechanic can work in any garage, ignoring the fact that there is likely a completely customized workbench layout with years of tools accumulated and placed precisely where they fit best. Making sure your developers are armed with laptops allows them to be physically mobile and gives them the ability to take their technological tools with them everywhere they go.

I also know that some developers heavily prefer their own computers over anything bought for them. I have seen several companies that allow the option of a “hardware stipend,” and they’ve had good results.

Allow Experimentation

Playing with new programming languages is fun. Passionate developers like to experiment with new languages. If you encourage them try new languages for projects, two things will happen: 1) they will increase their existing skill sets, making them more valuable as employees, and 2) their happiness will increase, usually resulting in them staying around for a long time. It’s been known for a while that Google has an 80/20 policy, where 20% of an employee’s time can be put toward things he or she finds exciting. And guess what they got out of it? Gmail. One of the largest email services to date. Give your employees a little freedom, and an idea they have might be the spark that ignites something awesome within your company.

Exciting Products

The hardest part about finding passionate people is having passionate products to work on. If you’re working on “the next Facebook,” no one is really going to care about it. On the other hand, if you’re working on a realtime zombie survival app, you will probably get a few developers knocking on your door saying they’re interested in working for you.

In short, take your products, skip the recruiters, and look for talent at local meetups. You’re much more likely to find someone who will be excited to work alongside you, and enthusiasm goes a lot further than lines of code these days.

The post Find Passionate People appeared first on Software for Good.

Recently I’ve taken over as lead on a project that is being used by some larger companies. It’s both exciting and intimidating to see something I’ve worked on for weeks become viewable on the public internet. However, I can’t take full credit for getting the project to where it is today.

I am not primarily a front end developer (HTML/CSS, the stuff you see when you load a webpage). I have a strong mobile background in both iOS and Android, and over the past few years I have been strengthening my Rails and JavaScript skills. There is a snowball’s chance in hell that I could have gotten this project done on time without the help of some other developers here at Software for Good. Shannon put down a great HTML & CSS foundation, and from there, I was able to start injecting AngularJS. Kyle mixed in some code to enable a fixed header and scrolling wp-content beneath, along with custom scrollbars for a consistent UI across all browsers. Sara did some QA testing. Nearing the end, Evan helped me to debug a few browser specific issues (yes, all IE related). All the while, I was working on the Rails backend, pushing out wp-content updates via Faye.

You have to be skilled to mix talent. You can’t just slam a bunch of developers in a room and expect better code and faster code production. Think about it: It takes a woman 9 months to make a baby, but 9 women can’t make a baby in 1 month. That’s not a totally accurate parallel to software development, but it gets the point across. Some pieces allow for only one person at a time, and adding more people won’t help. For a lot of projects, it helps to be able to break them up into smaller pieces and work on them simultaneously. Breaking things up takes planning and coordination, though. We don’t just all rush off in different directions.

The individual developers at Software for Good are great, and combined we are even better. But why stop there? Early this year, we announced that we’ve brought on space-loving Jamey Erickson, and we’re expanding out our Digital Solutions Team. With each additional team member, we’re expanding out our skill sets, bringing in more parts, and becoming a better whole.

Need a team to help you achieve your goals? Develop cancer vaccines? Manage instruments donated to public schools? We’ve got one right here.

Want to join our team? We’re looking for some top-notch software developers and engineers.Seriously. Start the conversation: info@softwareforgood.com

The post The Whole is Greater than the Sum of its Parts appeared first on Software for Good.

From a developer’s standpoint, the question is crazy. It would be similar to someone asking a car salesman, “How much does a car cost?” or a realtor, “How much does a house cost?” A used car can cost as little as a few hundred dollars, whereas a Bugatti Veyron has a base price of $2,500,000. But even that large of a span makes sense to most people, as cars have visible and tangible differences. Nobody bats an eye when they see a mansion listed at several million, but some people go crazy when you tell them that developing an app similar to Facebook will easily cost over several hundred thousand. As a developer, though, it makes sense. The part of an application that you see, what most people recognize as an app, is an extremely small piece of a much larger system. Application development cost is so commonly asked about and misunderstood that some websites exist just to answer that single question.

$2.5million and probably worth every penny

But why? We live in a technological age, and a lot of business plans regarding applications are well laid out. It all comes down to one thing: the ‘invisible’ technology–the technology that users don’t see but that actually runs an application–is expensive. For example, think about an application that mimics Twitter. We’ll call it Twaddle. The concept is fairly simple: Allow people to share 140 characters at a time. How expensive could it be?

(Disclaimer: Estimates and costs listed below are complete guesses. The point of this post is to provide insight into the multitude of hidden costs in application development, not their exact values.)

iOS App

We’ll start where most people do, with an iOS app. Assuming we are starting from scratch, we already have some large costs involved. Twaddle will need a design, which, when done by a professional designer, could cost upwards of $5,000. After the design is finished, an iOS developer will be required to code and implement the designs, which we’ll guesstimate to be about $7,000. $12,000 and we have our app completed! …right?

To the Cloud!

Not quite. At this point, we have an app, but it doesn’t connect anywhere. iOS devices cannot pass user generated wp-content back and forth directly, so we will need a server to manage that information. Not only that, but we’ll have to store it in a database. Server and database development are typically done in a conjoined manner, and many experienced backend developers (the ones who write the code behind a mobile app on a server) can do both. It is not cheap, though, and for Twaddle, it’s going to cost us another $5,000 to have someone develop this piece of the system for us. Once the code is finished, we’ll need to host it somewhere. Popular services like Heroku are good to start with because they are free initially and you can pay for increased speed and performance as more and more users start to use your app.

But wait! Now that I’m thinking about it, we probably also want people to be able to upload pictures. Pictures can’t be stored in a database (typically), and in order to allow people to share pictures, we’re going to have to store them somewhere. A common storage provider is Amazon S3, and while it has a nice free usage tier, once our user base increases, we could end up paying hundreds of dollars a month just to let people look at pictures!

And…roid

At this point, we have an iOS-only application that has a cloud-based backend, but it would be silly to not go for the large potential user base of Android users. A common mistake at this point is to tell an Android developer to take the existing design, originally styled for iOS, and implement on Android. It is so common that Google specifically tells us not to do it. We now need to go back to our designer to tweak the original design for Android devices. Thankfully it’s not a complete redoing of the previous work and will only cost us about $3,000. The downside is that Android device fragmentation is so extreme that it takes the Android developer longer, and therefore costs more money, to complete the Android version of Twaddle. Development ends up totaling $7,000.

More Than We Originally Expected

It’s common to think, “I just need design and development for an app,” so $12,000 doesn’t seem that outrageous. But once we take into consideration all of the other pieces, server infrastructure, cloud file storage, and separate Android design & development, we now have an app that has a base cost of $27,000 and a monthly recurring cost of several hundred dollars to run our servers. Keep in mind that this is for an extremely simple app and that it doesn’t take into consideration more advanced technologies that larger applications would require, such as load balancers, wp-content delivery networks, or a website for non-mobile users to use!

You Pick Two

Good, cheap, fast. You can only pick two. If you want good and cheap service, find a college student who has the capabilities to learn, but is going to take a while to learn all the intricate pieces of a full application system. If you want good and fast, you’re going to have to pay for an experienced developer who is expensive BECAUSE he (or she!) is good. And if you don’t want good, you probably shouldn’t be pursuing application development in the first place. A common “solution” to this problematic triangle is to use a cross platform mobile technology such as Xamarin, Titanium, or PhoneGap. Third party SDKs almost always compound problems rather than solve them. Titanium and PhoneGap, for example, both rely heavily on Javascript, which is a non-native programming language for both the iOS and Android platform. Going the non-native route results in a slower UI and bad performance–and your users will notice. Mark Zuckerberg himself admitted that HTML5 had performance issues when Facebook stopped using it on both their iOS and Android mobile apps and reprogrammed them using native code.

Shortcuts are bad, plain and simple, and you will most likely get burned if you try to take them. There are some tools, though, that can help decrease the cost of your application development. You could drop paying for a backend developer and use a system like Parse. This will require additional mobile side coding, so don’t think using a BaaS is free, however in my experience, I have found that it does reduce overall development time and cost, even if the mobile side does go up slightly. It’s also a good idea to work with developers who understand both iOS and Android. Development of brand new applications can prove tricky, however if it’s the same person doing it for both platforms, you have a greater chance that they look/behave/feel the same than if you had two completely different people developing each piece.

Application development can, and usually is, quite expensive. If you work with a skilled development team, though, *cough* Software for Good *cough*, they can help you to produce a polished product while working to reduce developmental cost.

The post The Hidden Costs of Apps appeared first on Software for Good.

I’ve had a few jobs over the past several years, though all of them have been in the realm of software development. Something I’ve come to realize recently is that none of these positions were bad – they just weren’t good fits for me.

My first heavy development job was as an iOS and Android developer at a blossoming startup, and I learned a LOT. Because they were based out of state, I was allowed to work from home every day in my PJs, but that meant that I was working all sorts of crazy hours. I was only the second developer on the project, and I’d get phone calls when one of our servers would go down, no matter what the time might be. We had clients all over the globe, and my current timezone didn’t matter. 10pm in Milwaukee is 3pm in Australia. They needed their app to work!

Eventually I realized that I could not continue to allow my social life to suffer. I don’t blame the company, as I was responsible for the way I was working. But I knew I needed something different, something that would push me toward a more positive work/life balance, so with a sadness in my heart I turned in my two weeks and moved on.

I knew that my next job would be different than the previous. At that first job, I had helped to shape the development team from the beginning. Now, at the next, I was merging into an existing development team with an existing system and process.

I loved the work I was doing, developing iOS apps and having a fantastic work/life balance, but over time I started to feel siloed. The company had many projects, with many clients, and it was hard to pin down someone for your team, as they might be working on three other projects at the same time. At times, I would be working on a prototype that required no other developers, so I’d be coding on my own. I also had to learn how to work with a project manager, which is something I hadn’t done at my last job. Before, I’d gotten used to managing all of my own projects, and having that handed off to someone else was a difficult transition.

As I had previously with my first position, I came to realize that the second job wasn’t the best fit for me, either. Through some developer happy hours in downtown Minneapolis, I came to know Software for Good and was eventually offered a job.

The best way I can describe working here is that it’s a combination of my last two jobs. The team structure is much more free flowing, and there is a greater overlap of projects between developers. Peter Edstrom does the bulk of project management (and a great job at that!), though I still get to meet with clients face-to-face in regularly scheduled meetings. I spend most of my day coding, and some days I don’t have a single meeting. One of my favorite aspects is that the communication is done the way I’m most used to and most prefer: asynchronously. It’s something that is loved by many people, including developers at GitHub. I almost never have someone tapping on my shoulder with a question, and I’m able to plug in my headphones and rock on some code until the cows come home. We use Campfire and Google Chat/Hangouts to communicate, and projects are tracked with Asana. One amazing outcome of this is that it doesn’t matter too much if you work from home for a day or if you’re in the office. During the snow emergency last week, I decided to work from home and not combat the horrible traffic, and my day was essentially unchanged. I checked in with the team via Campfire, and worked through the tasks listed in Asana.

One of my favorite aspects about Software for Good is that there is no sense of hierarchy or superiority. Casey, the founder and CEO, sits alongside everyone else at one of our giant tables. Some CEOs/founders/owners reside in an office, creating a physical barrier between them and the team. There is none of that here, and it feels awesome.

We also have no senior/junior developers – everyone is just a developer. If the guy who just started two days ago has an idea that contradicts the guy who has been here since day 1, we listen. Some people have asked me, “How do things stay organized if you don’t have a bunch of managers?” and the answer is pretty simple: everyone manages themselves. If I’m working on two projects, it’s my responsibility to communicate with those two clients and make sure the projects each stay on track. I know of some developers who would hate this and prefer to leave the management completely up to someone else, but personally I quite enjoy it.

There are two other major highlights to working at Software for Good: unlimited PTO and an open book policy. The open book policy shows a level of trust I’ve never experienced before at another company. Instead of profit coming in and being a mystery, I can see how the money is spent, what hardware purchases it goes toward, how much our rent costs, etc. It’s money WE have earned as a team, so we should all get to see how it’s spent, right? As for the unlimited PTO, most people might wonder why all of the employees don’t just take every day off. It’s because we are all smart adults who love our jobs, and if we stop coming into work, we stop making money, and we can’t pay our salaries. And if I had a job where I always wanted to take PTO, it probably wouldn’t be a job I should keep in the first place.

Every job I’ve had has been great, but Software for Good has been the best fit for my work style and preferences. Would it be the best fit for you? I can’t say. All I know is that I hope to be here for a long time.

The post Why I Love Working at Software for Good appeared first on Software for Good.

Update: Orangered Messages has been approved!

I <3 Reddit

Reddit has played a huge part in my career in all sorts of ways. My first iOS app was a Reddit app. I found a job on /r/forhire (Hi Core-Apps!) after my first serious employer ran out of money. I’m even wearing an un-purchasable Reddit shirt today!

It only made sense that my first OS X app fall in line and be a Reddit app as well.

Unsatisfied with the Competition

There’s an existing OS X app called “Reddit Notifier” that checks your Reddit inbox and notifies you when you have new messages. It’s a decent app, but it’s lacking in several areas. My three main problems:

1. It takes your username and password directly into text boxes, and I’m not exactly fond of turning over my credentials to a 3rd party app.

2. It doesn’t show how many messages are unread, only some or none.

3. It doesn’t tell me what my messages are. All I know is that there is one. Somewhere. From someone. Maybe.

Clearly it was time for an update, so I set off to build something better.

More Secure Authentication

Step 1 was to dig into Reddit’s API to figure out if I could use a more secure form of authentication. Turns out I was in luck, and their API supports OAuth! I’m generally a fan of writing a custom API client, so I built one on top of the amazing AFNetworking.

I hadn’t used it since they published 2.0, so I had to go over their migration guide to get an understanding of the breaking changes. After access_tokens are received, user authentication is done via bearer tokens being passed in the Authorization header.

Checking for Messages

Once I obtained an authenticated user, it was easy enough to hit /message/inbox and count the number of items returned with new set to 1. iOS has no UI element like NSMenuItem, though it was pretty straightforward to get a nice menu working with an unread message count.

Killing two birds with one stone, I also decided to present the most recent 20 messages. When clicked on, it will bring you directly to the context on where it was posted.

Digging Deep and Going Beyond

At this point my app was good, but it wasn’t GREAT. After using Mavericks for a few days, I yearned for the ability to quick reply to Reddit messages just like I do with iMessage and Airmail. I checked the OS X documentation for NSUserNotification, but I couldn’t find anything relating to the ability to reply to a notification.

I searched Google and StackOverflow, but I couldn’t find anything! Where was this elusive reply ability?! Finally, I dug into the OS X 10.9 API Diffs and found it near the bottom of the page for Foundation updates.

I went back to check the NSUserNotificationActivationType, and sure enough the reply one is missing.

Oh well. It didn’t matter because I had found it! I quickly coded up my alerts to use the new notification methods and had a working QuickReply!

What I Learned

I learned a lot, cramming the development of this app into one weekend. I learned that you can’t always trust documentation, even when it comes from a giant corporation like Apple. I was reminded that not all OAuth2.0 providers follow authorization methods to the exact spec, that AFNetworking is awesome, and that even when something out there exists, that doesn’t always mean that you can’t make something else that is better. It was a fun and exciting project, and I hope it gets approved sometime within the next few days!

The post Writing a Mac App appeared first on Software for Good.