"development" entries

Signals from the O’Reilly Software Architecture Conference 2015

From careers to culture to code, here are key insights from the O'Reilly Software Architecture Conference 2015.

Experts from across the software architecture world came together in Boston for the O’Reilly Software Architecture Conference 2015. Below we’ve assembled notable keynotes, interviews, and insights from the event.

Software architects: post-“post-useful”

The old notion of a software architect being a non-coding, post-useful deep thinker is giving way to something far more interesting, says Neal Ford, software architect and meme wrangler at ThoughtWorks. “Architecture has become much more interesting now because it’s become more encompassing … it’s trying to solve real problems rather than play with abstractions.”

Read more…

Everything is distributed

How do we manage systems that are too large to understand, too complex to control, and that fail in unpredictable ways?

Complexity

“What is surprising is not that there are so many accidents. It is that there are so few. The thing that amazes you is not that your system goes down sometimes, it’s that it is up at all.”—Richard Cook

In September 2007, Jean Bookout, 76, was driving her Toyota Camry down an unfamiliar road in Oklahoma, with her friend Barbara Schwarz seated next to her on the passenger side. Suddenly, the Camry began to accelerate on its own. Bookout tried hitting the brakes, applying the emergency brake, but the car continued to accelerate. The car eventually collided with an embankment, injuring Bookout and killing Schwarz. In a subsequent legal case, lawyers for Toyota pointed to the most common of culprits in these types of accidents: human error. “Sometimes people make mistakes while driving their cars,” one of the lawyers claimed. Bookout was older, the road was unfamiliar, these tragic things happen. Read more…

Repeatable Development Environments with Vagrant

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.

Read more…

You Can’t Legislate Away the Time, Money and Features Law

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.

Read more…

Conquering iOS Core Data

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.

  • What exactly is core data? [Discussed at the 0:18 mark.]
  • Which is right for your persistent data – Atomic, memory, or NSSQLite? [Discussed at the 2:15 mark.]
  • Core Data is hard to learn, not use. [Discussed at the 3:51 mark.]
  • Using templates like Helios or MagicalRecord can make things easier. [Discussed at the 6:04 mark.]
  • Concurrency within core data is all about the context. [Discussed at the 6:41 mark.]
  • What are the differences between how Android OS and iOS handle data structures? [Discussed at the 9:50 mark.]
  • You can view the entire interview in the following video:

    Read more…

    Location, Location, Location

    Why where you put your script element matters

    Everyone knows you add JavaScript to your page by putting your <script> element at the top of your HTML page, right? Not so fast. In part two of Head First JavaScript Programming Teasers, Eric explains the nuts and bolts of the <script> element: how to add it to your page, and where.

    While you can put a <script> element just about anywhere in your code, there are a couple of things you should know before you make any decisions about where to add it. For instance, you might already know that the browser reads your page top down and starts executing your JavaScript as it gets to the code. That means if you put your JavaScript in the <head> of your document, the browser will execute the code before it loads the rest of the page. That might be what you want… or it might mean that users are sitting there looking at a blank page while your script is executing.

    Watch the video for a couple of other tips about the <script> element, taken from our upcoming book, Head First JavaScript Programming.

    And if you missed the first part of this video series, you can watch it here.

    Yet another JavaScript book?

    For the next 15 weeks, a new learning video every week.

    Eric Freeman and I are writing a new book: Head First JavaScript Programming, and to go along with it, we’re creating a series of teaser videos to give you a taste of what’s coming in the book, and a chance to learn a few JavaScript tidbits.

    Why undertake writing a JavaScript book now? After all, isn’t there already a Head First JavaScript book (not to mention all the many other JavaScript books on the market)? Well, to make a long story short, when we published Head First HTML5 Programming, a book that teaches you how to use all the new HTML5 APIs (with JavaScript, of course), we discovered something: a lot of folks know a little JavaScript, but really want to understand it at a deeper level. They want to go beyond just simple scripting. To remedy that, we ended up taking a month to write a brief introduction to JavaScript in our Head First HTML5 Programming book, but it wasn’t enough. Readers needed more.

    Read more…

    What is probabilistic programming?

    Probabilistic languages can free developers from the complexities of high-performance probabilistic inference.

    Probabilistic programming languages are in the spotlight. This is due to the announcement of a new DARPA program to support their fundamental research. But what is probabilistic programming? What can we expect from this research? Will this effort pay off? How long will it take?

    A probabilistic programming language is a high-level language that makes it easy for a developer to define probability models and then “solve” these models automatically. These languages incorporate random events as primitives and their runtime environment handles inference. Now, it is a matter of programming that enables a clean separation between modeling and inference. This can vastly reduce the time and effort associated with implementing new models and understanding data. Just as high-level programming languages transformed developer productivity by abstracting away the details of the processor and memory architecture, probabilistic languages promise to free the developer from the complexities of high-performance probabilistic inference. Read more…

    Code Simplicity: The science of software design

    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.

    Read more…

    Mobile developers, integration, and discovery are what count now

    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.

    Read more…