I Am Finley

Web Development

Core Development Principles


Development shops are relying on the communications team at a finance agency to know that they should request their code be optimized for performance or accessibility. I’m going to go out on a limb here and say that shouldn’t be the client’s job. We’re the experts; we understand web strategy and best practices—and it’s time we act like it. It’s time for us to stop talking about each of these principles in a blue-sky way and start implementing them as our core practices. Every time. By default.

A List Apart

I’ve been in the web industry for 15 years, grew into my own during the web standards revolution, and have a huge heart for a11y issues. Seeing our industry revert to, in many ways, the methods and practices from before the standards movement is disheartening at best. We need, now and always, to insist on core development principles.


Using the iPad for Web Development


Here is another great article on web development on the iPad. This stood out to me as I had the same thing occur the other day:

Not all is rosebuds and blue skies though, as Coda has quite a few issues that make it less than ideal for all circumstances. First, the app is very prone to crashing. I’ve had quite a few crashes that I just can’t explain. The app will simply stop responding at random points while I’m typing and not respond until I force quit and restart the app.

I built the website for Ergo Web Tools in Coda after designing it in Graphic. Every once in a while the app would lock up while I was typing and never catch up. I’d have to force quit the app and relaunch it. What’s nice is that Coda remembers your place in a “site” when you come back, but the bad news is if you were running any process in a Terminal tab, it doesn’t restart.

I develop on a Digital Ocean droplet where I have Sass, Grunt, and more tools installed for easy access. So I have to, when Coda decides to lock up, restart my “sass --watch” command. When this happens a dozen times over a couple hours of coding, it is rather frustrating.

Over the next week I’ll likely be sharing a bit more of my design/dev process and some requests that I’d have for the developers behind the apps I’ve been using. iOS has made huge strides over the last few years and doing “real work” is becoming even more plausable.


“Real Work” and iPad


At some point, the difference vanishes. Most people never did “real work”, by whatever metric, on their computer; they were happy to browse web pages, send emails, Skype friends, whatever. Yet the redoubt of “real work” is defended valiantly, perhaps by those whose jobs depend not on the work, but on the tools used for it – the PC. It’s very notable how often those defending the “real work” divide are also systems administrators of some sort. It’s as if, like the London cabbie, they felt their employment was in peril, while everyone else adapts around them.

For myself, I ask “What do I need to be able to do my job?” LAMP environment? I set up a Digital Ocean droplet that I can SSH/SFTP into. Sass and Grunt? All set up on the droplet. FTP client and code editor? Coda for iPad is fantastic. But I’m a front-end developer, so the browser is a key tool in my toolbox. I need a web inspector to see what styles are applied to an element. I need a way to test responsive websites across many sizes. I need a JavaScript console to look for errors and help with debugging. There are a few apps for viewing the source of a page, but that doesn’t quite scratch my itch. There are a few apps with a simple console, but none of them really work well with the iPad’s big screen. They all seem built for iPhone and enbiggened for iPad.

So what is a front-end web developer to do? Before Thanksgiving I started doing a lot of research and over Thanksgiving weekend (which was nice and extended for me) I started to build something special.

I call it Web Tools. Keep it simple, right? To start (1.0), Web Tools has a scalable web view that allows you to test any width you want and a web inspector to allow you to easily drill down through the DOM tree and see what styles are applied to each element. And this is just the start. More great features are coming to Web Tools in the coming months, including a powerful JavaScript console.

Building websites on the iPad, even an iPad mini like mine, is a joy when you have the right tools. So I am working to bring desktop-level tools to the iPad to remove excuses. As Twitter says, it’s the #yearofticci.

Web Tools launched today and can be had for a $5.99 introductory price. Head over to the App Store andbuy a copy!


iPad Pro and Me


On Saturday I took a trip to Best Buy to play with the iPad Pro. And that sent me on a research trip over the weekend to see if it could replace my current setup. Right now I have a MacBook Air and a iPad mini. The MacBook is used for development and design work and the iPad is used for everything else. Unfortunately, the iPad Pro is way too large and awkward for use in bed, so I feel I would need to keep the iPad mini for that. And, so far, the “pro” software for iPad isn’t good enough to fully replace my Mac needs.

Here is how I see my uses:

Where design apps lack on iOS is slicing and outputting graphics, something required for development. If Pixelmator or Graphic allowed you to quickly slice and output images on iOS, I wouldn’t need a Mac for that.

Beyond that, I need Xcode for iOS. There is Dringend, but it requires a remote Mac to compile and it cannot open Storyboards/XIBs. Some of my projects are Storyboard/XIB free, but not all.

I would love to be able to replace my Mac with an iPad Pro, but unfortunately I cannot yet. I can use an iPad Pro for a lot of what I do, though. So I am considering one.


Virtual Hosts and Mobile Development


Virtual hosts are such a great tool for web developers to test locally without losing their mind, but web development in 2015 involves testing on far more than a single machine. If your mobile iOS devices are on the same network, here is a simple trick.

  1. Go to System Preferences on your Mac.
  2. Go to the Network panel.
  3. You should see your IP address in here. Mine right now is
  4. Go to Settings on your iOS device.
  5. Go to the Wi-Fi section.
  6. Tap the info icon on your current Wi-Fi network.
  7. Scroll down to the HTTP Proxy and tap Manual.
  8. Enter the IP address you found above into the Server field.
  9. Enter 80 into the Port field.
  10. Go to your browser of choice on the iOS device and go to your virtual host.

Simple enough for quickly testing your websites.