Always Get Better

Posts Tagged ‘standards’

That’s Not My Job

Friday, March 13th, 2015

Most companies seem to have a group of people who gravitate to either front-end or back-end development. I’ve been struggling to wrap my head around this because it doesn’t seem like a useful dichotomy.

It’s a fast-moving field, do you really want to carve a niche as a Unity programmer? An ActionScript expert? A Sharepoint developer? If you specialize to that degree, what happen

s when your technology of choice moves on?

How many of these have you come across:

“Front-end” developers who don’t understand the HTTP stack.

Companies that don’t have centralized source control.

“Back-end” developers who believe front-end code should be unit and performance tested just like server code – who don’t understand why squeezing maximum performance for one user on one machine would be as challenging as constructing a web app that served thousands of users at the same time.

Web designers who don’t know HTML, CSS and jQuery.

Anyone who takes a laissez-faire approach to security.

Project groups that don’t use Continuous Integration.

Understand More

Everyone has an area of interest where they excel and you should definitely pursue yours. Never forget that yours is a piece of the whole, and the more you understand of the whole the better you will be able to create value with your work.

If Photoshop is your bread and butter, learn how programmers slice your designs into HTML. Understand the technical limitations and get inspired by what the web browser can do for you.

If you’ve been slinging awesome responsive webpages, use your JavaScript skills to learn Node.js and understand where that server data is coming from and how it is stored. Expand your ability to write front-ends that scale as beautifully as they present.

If you are more comfortable in the bowels of a Linux server, download Cocos2d-x and experience the thrill your front-end counterparts get when their math turns into gorgeous sprites on-screen.

Everybody’s Talking

Every time you learn something new you open up a world of people you can network with and understand at some level.

Whenever someone asks how to get into the field, what do you answer? “Just do it!”

Native Languages are Best for Mobile Development

Monday, July 14th, 2014

Like it or not your clients want mobile and if you are a developer without experience in this realm you are behind the curve.

Having been mobile-centric for the past three years of my professional life, I have heard all of the different lines of thought around toolsets and approaches for creating software targeting these devices. Moreover, I’ve lived through a lot of those toolsets and approaches, and have spent time thinking about which worked well and which ones, well… sucked.

It all boils down to this:

Build native apps using the tools and languages provided by your platform.

Yes, this is the same position I held when I wrote about this almost two years ago, but I stand by it. I’ve had a chance to play and build with the likes of Adobe Air, PhoneGap/Cordova, SenchaTouch and Xamarin, but I always end up going back to Java (Android) or Objective-C (iOS) because…

Cross-Platform Isn’t Good for Anybody

Your app is iOS only… are your installed customers complaining about it not being on Android? No! Why would they care?

When talking about a new project one of the first things to come up is the idea of using X tool so we can build to a lot of platforms after writing the code once. I guess the thinking behind this is somewhere along the lines of “if we make our product available to more people, then it follows that more people will obtain it and we will make more money”. I don’t buy this.

Look at it this way – you’re up against a million apps. What sets you apart? How do you communicate that to all of your potential customers? Are downloads from the Windows Store equivalent to downloads from Google Play? Do they use their phones in the same way and monetize the same way? Are the demographics the same?

If everyone was the same, it would still be a bad idea to build your app around a cross-platform framework. Invariably these work in a lowest-common-denominator fashion meaning you get universal support by trading off native features. Yes, your app runs the same on all the platforms, but Android users are accustomed to navigating using their back button, which iPads don’t have. Instead of providing beautiful context-sensitive navigation using activities for Android and NavigationController hierarchies for iOS, you get uniform views.

“Universal” is a Lie

Okay, so most development kits come with a way to plug in your own native code for the device-specific goodness (better GPS, camera gestures, whatever). Now you’re writing native code anyway, and you’re on the hook to support all those platforms. So why would you want to go through the pain of hooking all that into a cross-platform tool instead of going directly to your platform in the first place.

Worse, your universal framework has bugs. I’m sure it’s great software but all software has bugs. When you hit a bug that stops you from moving forward, what are you going to do? When the underlying operating system software changes and your framework hasn’t been updated yet, are you not going to deploy until the author gets around to supporting the new requirements? When you choose a cross platform tool you are choosing someone else’s opinions and priorities and ceding control of your own product.

My recommendation is to pick a release target and excel at it. Will it be in the Apple ecosystem? If so, don’t be afraid to go all in. Learn how iPhone users are going to interact with your software and do everything you can to speak to them, please them, and turn them into paying customers. They don’t want a great Android experience, they want software they don’t even think about. They won’t patiently deal with your buggy software because you were so afraid of missing out on customers that you greedily deployed a boring app just to support some other platform. The “smaller” number of users is still a lot of users!

I get the fear factor, but the cross-platform tools are designed to make life easier for developers, not customers. The developer isn’t buying my product – I don’t care so much if he’s worried about synchronizing features in a future Android port of the app.

Speed is King

I want my app to load fast and I don’t want to wait around for it. You can’t get more performance than a well-written app build from native languages and tools. Don’t be afraid of XCode, Visual Studio and IntelliJ – embrace them and enjoy the barebones software you can build with them.

Thinking in New Paradigms

Suppose you do want to put your app on two different kinds of devices. Now you need to maintain your program logic in two programming languages, adding new features and squashing bugs in both places. That’s not really such a bad thing.

What if you have an ENORMOUS code base with hundreds of thousands of lines of code – how will you ever keep that synchronized between two development tracks? Well, you might a good candidate to actually use one of those cross-platform tools. Or you might be asking yourself if your work load is really appropriate for a mobile experience (something they won’t tell you — not every app belongs on a mobile device).

Apps don’t need to behave the same on different device formats. Every modern operating system has a different focus and enormous capability list that becomes adopted by its users – so evaluate what it is really like to use your app on each device. Especially for UI stuff – do you need backward navigation on Android when there is a hardware button for that? What buttons can you eliminate on iOS in favour of multi-touch gestures?

In the past 5 years I’ve added Java, Scala, Ruby, JavaScript (specifically, Node.js-style callbacks), Objective-C and lately Swift to the list of languages I’ve used extensively and thought deeply about. Each one has challenged me to look at programming differently and apply new practices to older thought patterns. Working withing multiple native environments is not a hindrance, it’s a huge boost to the quality of software you can create.

Streamlined Learning

When you use a cross-platform tool, you have an extra learning curve – that of the tool itself. I don’t buy into the thought that it improves your productivity, but I definitely see where it decreases your productivity. You need to be aware of bugs in your tool (as we mentioned earlier, your tool is great but it’s still software and software has bugs), you need to be aware of the capabilities of your tool including all the new features they add (which, by the way, just expose native features you should have been working with directly all along).

If you can avoid it, skip the cross-platform stuff and go right to your actual platform.

Putting it all together

As a programmer your job is not about writing code, it’s about connecting businesses with their objectives. A good technologist doesn’t get caught up in ideology over which approach they ought to take to build software – they decide which implementation detail will get them to their goal. So if a cross platform tool makes sense for your project, use it. Just be sure that you’re picking the right tool, and not the comfortable (for now) one

Multiple Development Environments

Friday, November 4th, 2011

Hopefully when you do web work, you’re not developing code on the same server your users are accessing. Most organizations have at least some kind of separation for their development and production code, but it’s possible to go far further. Separating environments allows you to achieve multiple threads of continuous integration for all kinds of cool.

These normally break down as follows:

Working code copy. Changes made by developers are deployed here so integration and features can be tested. This environment is rapidly updated and contains the most recent version of the application.

Quality Assurance (QA)
Not all companies will have this. Environment for quality assurance; this provides a less frequently changed version of the application which testers can perform checks against. This allows reporting on a common revision so developers know whether particular issues found by testers has already been corrected in the development code.

Staging/Release Candidate
This is the release candidate, and this environment is normally a mirror of the production environment. The staging area contains the “next” version of the application and is used for final stress testing and client/manager approvals before going live.

This is the currently released version of the application, accessible to the client/end users. This version preferably does not change except for during scheduled releases. There may be differences in the production environment but generally it should be the same as the staging environment.

Having separation between the different environments is not tricky, but managing your data environment can be. There are, of course, all kinds of ways to solve the problem.

Adobe Aquires Typekit

Monday, October 3rd, 2011

Today Adobe announced its acquisition of Typekit, a web font hosting service that allows designers to use any typeface with their sites rather than relying on standard “safe” font families.

This is an interesting development. Adobe’s Flash player already supports proprietary fonts, which suggests that the company is looking at alternate technologies for its future development. Obviously Flash will remain relevant for more time to come, but as competitors increasingly jump onto the HTML5 bandwagon, Adobe is wise to increase its arsenal of standards-compliant technology.

Memcache as MySQL’s Hero

Sunday, April 10th, 2011

It’s hard not to love memcache. As soon as you manage a web site that has more than a few concurrent visitors, the performance benefit of caching becomes immediately obvious. MySQL is a fast database and can outperform a lot of its competitors, but no matter how quickly it can pull results it can never outperform the retrieval speed of the server’s RAM.

The basic premise is: instead of pulling a model out of the database, see if it has already been loaded into memory by checking a key-value diction (for example: User5677). If the user has not been read from the database yet, the key-value store will be empty and we can fetch the record. Next time we need that data we check the key-value again and avoid querying the database.

This really saves us whenever we have data that changes infrequently. Take, for example, an ecommerce website: since the products and categories on the site will change very rarely, it makes a lot of sense to store them in memory for fast recovery. Even more volatile information (like user data) can be stored in the cache, as long as the application knows to empty that cache key when the data gets changed.

Memcache is an ideal tool for managing these kinds of caches, and provides a lot of flexibility for growth.

History Lesson
Earlier this week I promised to go deeper into memcache’s origins. Memcache was originally developed at Danga as a way to reduce the database load and improve the speed of LiveJournal.

Rather than developing a standalone server application, Danga’s engineers designed memcache to sit on lower-end hardware and on web servers where it would use a small amount of the overal memory. Memcache instances don’t talk to each other: the client machines are aware of all the memcache instances and attempt to write their information evenly to each. This allows memcache to scale almost limitlessly without adding significant overhead to the caching process.

When to Use
Quite simply: if you’re building an application for the LAMP stack, build in memcache support. When treated as a necessary component from the beginning, caching support adds almost zero overhead to development; however it will always pay off as soon as real world traffic is coming to your site.

BrowsrCamp – Test Web Designs on Mac

Friday, November 13th, 2009

At last, remote desktop has a practical use!

If you are working on a web design and need to see how it will look on Mac, your only choice up until now has been to buy a low-end Mac. That’s an expensive proposition for occasional use. If you’re a web designer by trade you are probably already using a Mac anyway, but for the rest of us there is finally a better choice.

Head on over to BrowsrCamp – for a pittance ($3 gets you 2 days of access) you get to control a machine running OS X.

You can use VNC to connect to the server; if you don’t have or can’t install VNC, BrowsrCamp offers a web interface so you can access the machine directly from your browser.

It’s such a simple, wonderfully executed concept that should be in any programmer’s bag of tricks.

When You Focus on Getting Better

Tuesday, November 10th, 2009

It seems like correcting Seth Godin is a favourite pastime enjoyed by folks online. Sorry to break from the group, but I happen to think he is a deep well of relevant information.

This week he brought up the idea of upsides versus downsides – how much effort do businesses put into minimizing their downside versus the time they put into offering the best user experience?

One of the primary examples from the post is that of a hospital spending a huge amount of time doing paperwork to prevent litigation and prevent people from getting worse when their primary goal (and reason for existing) should be improving the lives of the patients coming through their doors.

The hospital example was interesting and timely because in “real life” the Jewish General Hospital recently came out and said it has been able to improve patient care (upside) by reducing errors (downside) through its new(ish) full disclosure policy. This ties in nicely with Seth’s article because it proves that it is possible for even large organizations to let go of the status quo and achieve new levels of excellence.

In the case of the Jewish General Hospital, it seems paradoxical but by admitting and dealing with errors, the hospital is actually less likely to be sued and face costly litigation. In essence, they have found a way to improve patient care, cut costs, and foster an open corporate culture. Way to go!