B!? Links

Being a good developer means to be inquisitive, curious and pragmatic. Never religious. Never dogmatic. Curious means that we should be eager to learn about all the things mentioned above and many many more. Inquisitive means that we should investigate and question all the things we learn. Pragmatic means that we should choose the right tools, being technologies, methodologies or techniques, for the job.

Timely reminder — there is no silver bullet or “one size fits all” methodology for tackling every software project.

[source: Crafted Software]

• Overplanning/analysis/meetings
• Project mismanagement
• Wrong choices of staff motivation techniques
• Wrong selection of metrics and evaluation methods
• Documentation strategy mistakes

An interesting case study.  Kudos for documenting the process and lessons learned.

There are over 3 million distinct links in the Stack Exchange network. Over time many of these links rot and stop working.

Recently, I spent some time writing tools to determine which links are broken and assist the community in fixing them.

Some highlights from Matthew Wear’s selections:

“It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility.”

“Here is a minimal list of the things that every software professional should be conversant with: • Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books. • Design principles. You should know the SOLID principles and have a good understanding of the component principles. • Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design. • Disciplines. You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming. • Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.”

“The frenetic rate of change in our industry means that software developers must continue to learn copious quantities just to keep up. Woe to the architects who stop coding—they will rapidly find themselves irrelevant. Woe to the programmers who stop learning new languages—they will watch as the industry passes them by. Woe to the developers who fail to learn new disciplines and techniques—their peers will excel as they decline.”

“Sometimes the best way to solve a problem is to go home, eat dinner, watch TV, go to bed, and then wake up the next morning and take a shower.”

“Remember, as a professional it is your job to help your team create the best software they can. That means that everybody needs to watch out for errors and slip-ups, and work together to correct them.”

“School can teach the theory of computer programming. But school does not, and cannot teach the discipline, practice, and skill of being a craftsman.”

In-App Purchases for iOS games. It’s a bit of a sensitive topic really, not many people like them at all, and quite a few people hate them and the impact they have had on the iOS games market. But today I want to explore the reason for their prevalence and explain why it has become an important part of the market for developers. I also want to reframe the discussion from one of “In-App Purchases are a problem” to one where we consider how they are being used and what developers could do to improve their implementation.

[I]f you think you’re missing any of the qualities below, don’t be offended. I didn’t pick these up for a while, either, and many of them came from watching other programmers or reading their code.

Most of these faults were discovered the hard way by the author himself, either because he committed them himself or saw them in the work of others.

Over the weekend, a couple of hundred iOS rockstars gathered together in Melbourne for the One More Thing conference. It’s a 2-day, iOS-focussed event and was very well run. Speakers included people behind Doodle Jump, AirSharing, Elements, iA Writer, Camera+, Tweetie, Hook Champ, Tapatalk, Planefinder, Calvetica, Pano, Flipboard, Trainyard and more. The apps created by the attendees were equally awesome. The format was nicely anecdotal and I definitely learnt a lot. I’ve summarised some of my takeaways into 56 nice digestible little chunks below. I’m paraphrasing from a lot of people so if anyone has any corrections or additions just reach out. The organisers are going to publish videos of the talks on their website and I you’d be crazy not to check them out when that happens.

We’re thrilled to announce that all of our apps have been upgraded from REE to Ruby 1.9.3. We wanted to share some notes about what went well, what went wrong, and what we learned in the process.

If you expect a “user-friendly” introduction to usability and that the history of usability is full of well-defined concepts and lean methods, you’re in for a surprise. Usability is a messy, ill-defined, and downright confusing concept. The more you think about it—or practice it—the more confusing it becomes. We learned that the history of usability is a “perverse journey from simplicity to complexity”.

APIs are UX for developers. I’ve always been surprised that there isn’t more material written about this aspect of our work, in a way that’s specific to the popular platforms.

Most web interfaces nowadays are designed based on the premise that users will be interacting with them using a mouse and a keyboard. While that may still hold true for the most part, there is a clear trend where users are increasingly expecting web interfaces to work just as fine on touch-enabled devices. Unless you build a native application and explicitly redirect your users to it, there is little you can do to prevent them from using your web interface on an iPad and getting frustrated along the way.

• Exclusive: building native iOS apps with RubyMotion
• MacRuby on iOS – RubyMotion review
• My First Impressions of RubyMotion
• RubyMotion and Interface Builder…
• RubyMotion Screencast
• Ruby Rogues: ep. 055 RubyMotion with Laurent Sansonetti

Instead of “pretty”, think of this as a guide to make code readable like a good essay.

Decorators have emerged as one pattern that’s helped us keep code ready for change. We’ve chosen our spots carefully, but it’s proven useful quite often.

What does it take to be a professional?

Done right, skeuomorphism can retain the simplicity and ease of use of an interface while empowering users to act.