ENTRIES TAGGED "development"
Introducing a common configuration format and workflow
As the number of developers on a project, the number of projects in an organization, or the complexity of a single project increases, it also becomes increasingly difficult to keep development environments operational. From changing dependencies and differing server versions to developers running completely different operating systems, keeping the process of getting a running development environment sane and repeatable is non-trivial.
Vagrant solves all of this by introducing a common configuration format and workflow for describing and building development environments repeatably across Mac OS X, Windows, or Linux.
More Lessons from the Collapse of healthcare.gov
Last week, I wrote in some detail about some of the specifics of how the Federal healthcare portal seems to have violated basic principles of good software delivery. Now I want to talk a bit about the more general factor that I think led to all those cut corners and shoddy deliverables.
One of the oldest and shortest jokes in the computer industry is “Time. Money. Features. Pick any two.” To some extent, you can swap quality out for features, because poorly delivered functionality is essentially non-existent functionality. In almost all commercial software projects, time and money both end up being the parts that give in the end. In other words, the original feature set almost never gets cut, but the project goes over budget and delivers late.
Worth the Blood, Sweat, and Tears?
Joshua Smith (@kognate) is a Lead Mobile Developer at iRx Reminder, frequent Cocoa Conference speaker and author of an upcoming book with O’Reilly on core data. We recently sat down to talk about core data and its complexities.
You can view the entire interview in the following video:
Why where you put your script element matters
And if you missed the first part of this video series, you can watch it here.
For the next 15 weeks, a new learning video every week.
Learn to be a better programmer by taking charge of your interests
If you want to be a better programmer, a good first step would be to choose an area of software development to take additional responsibility for. Now, when we say “responsibility,” we don’t mean the sort of “you’re to blame and you accept it” responsibility that is so commonly thought of. Instead, we mean the willingness to take charge or the willingness to do something about an area.
So select out some area of software development, and decide to be a bit more responsible for it than one was before. The “area” could be simply some additional part of the current project you work on, the whole project itself, some type of software development that you haven’t done before, some aspect of software development you’d like to know more about, etc. If you’re feeling adventurous, try deciding that you’re personally responsible for the quality of the entire software project you’re working on. If you do, you may be surprised at how much easier this makes your life. When you’re trying to maintain the quality of only a piece of a software project, it’s very difficult. You’re surrounded by complexity or confusion, and you have to fend it off at every turn. But when you look at the project as a whole instead and try to decide what should be done with it as a whole, the solution presents itself much more readily. Now, it may seem like quite a bit more work to resolve the problems of the whole project, and it is. But it’s considerably more satisfying, tremendously more effective, and will bring you up to seniority as a software developer much more quickly than just trying to solve the problems of your one particular area.
Three new battles to watch as the mobile hardware gap closes.
The iPhone 5 may or may not be the most beautiful handheld device, but it barely matters anymore. Competitors have rendered its beauty and craftsmanship irrelevant. Amazon has received the message and responded with its latest set of tablets, and Google has responded with the Motorola Droids and the Nexus 7. These devices now have sufficient quality in their materials, specs, and base operating systems so that they can make any consumer happy. So if hardware is a toss up, where will the next battles be fought?
The answer: developers, integration, and discovery.
First, the very best developers will build apps that tap key trends: improved camera quality is making real-world text and face recognition more possible, geofencing data stores are making proximity–based apps more possible, and despite Steve Jobs’ assertion that God gave us 10 styli, there’s clearly a host of applications that are benefiting from pressure-sensitivity and pens. The level to which Apple and Google embrace these new technologies and extend the current state of the art in voice and gesture recognition will factor heavily into the quality and emergence of new applications. In addition, the extent to which Apple and Google can expose these new technologies — like NFC or always-on Glass cameras in Google’s case — will provide an advantage to developers.
Christopher Neugebauer on Android interfaces, Jellybean, and future updates.
Chris recently wrapped up his work on Meebo for iPhone, Android and BlackBerry which was recently acquired by Google. I got a chance to talk to him at OSCON this summer about Android development.
Key points from our full discussion include:
- Great features from Jellybean are available for older OSes. [Discussed at the 2:32 mark]
- Android devices vary greatly in size and shape – design with this in mind [Discussed at the 4:35 mark]
- Developers need earlier access to new versions of the OS [Discussed at the 5:32 mark]
You can view the entire interview in the following video.
Web ops and performance questions with Sergey Chernyshev.
A profile of web operations and performance expert Sergey Chernyshev, director of web systems and applications at truTV and organizer of the New York Web Performance Meetup Group.
It's time to recognize and appreciate highly engineered health information systems.
Clinicians often encounter multi-step software processes that seem laborious. Sometimes that's due to a design flaw, but other times that process has been intentionally constructed as a crumple zone.