Blog logoMatthew Lang

Web Development

A 5 post collection


My web development setup for the iPad Pro

 •  Filed under Posts, iOS, Web Development, Tools

While it was my intention to write about my web development workflow on my iPad Pro at a later date, one of my readers got in touch asking about how I use the iPad Pro in this capacity. Rather than hold off I thought it would be a good time to elaborate a bit on my workflow when using the iPad Pro for web development. What follows is still under review and isn’t my first attempt at using an iPad Pro for web development.

My first iteration on using the iPad Pro involved the Blink app and setting up a remote development environment on a DigitalOcean server. This took a while to setup but even then I found that using Vim as my text editor on a touch device didn’t work for me. So it was back to the drawing board and what follows is a second pass at putting together a web development environment for the iPad Pro. It certainly isn't final but it’s working for me now.

Another point to consider is that this web development environment is tailored towards Ruby on Rails development. A similar setup will work for other languages and frameworks providing you can run your development environment locally in iOS or on a platform like Heroku or Engine Yard.

Remote services

I'm using a number of remote services not because I need too just to be able to work on an iPad Pro, but because they're already part of my workflow on the desktop and I can use them on the iPad Pro as well.

Github

I’m using Github for source code management for a number of reasons like client familiarity, Heroku integration and a few other reasons. The main reason I'm using Github though is that it's tried and tested. You can't argue with that.

I've tried a number of source code management services like Gitlab and Bitbucket. While there are benefits and drawbacks to each service, Github is my preferred source code management service.

Heroku

Heroku has been my go to hosting platform for Rails applications for a long time now. I’ve tried other platforms and while they might be good fits for particular clients with specific needs I’ve found that Heroku has everything that I need for hosting most Rails applications.

I’ve already mentioned that github is good for Heroku in that it’s baked into the pipeline service that Heroku offers. Automated deploys are a great thing and using this in conjunction with Heroku’s CI tool is one less thing for me to configure.

Client side apps

With our remote services in place it's time to focus on the client side apps. Apps that focus on developer productivity have largely revolved around other things that developers do like project management, issue tracking and documentation but there are more text editor apps becoming available on iOS and I’m confident that there will be even more apps like this overtime.

Working Copy

I’m using Working Copy as my local Git client. I’ve been using this for a few months now. It's easy to setup and it works well in iOS 11 with split view and the drag and drop functionality. Working Copy also integrates well with GitHub, Bitbucket and Gitlab. So I’m not tied to using one particular Git source code hosting service.

Text Editors

And now the essential bit of kit for any developers toolbox, the text editor. I’m running two text editors at the moment with the hope of selecting just one of these when I’ve given each of them a thorough test.

Textastic

I’ve used Textastic in the past but only as a means to edit text files remotely. Using it now as a text editor means that it needs to tie in with Git, have the essential settings I need for editing source code and perhaps the most important feature of all, a nice colour scheme!

Textastic-and-Working-Copy-together

So far I’m pleased with its feature set and there’s been little in the way of blocks when it comes to workflow. Once I had Working Copy setup to track my Github repos, I was able to drag a branch into Textastic and start working. Changes to files are marked in Working Copy so that you can commit your changes as you normally would.

Textastic doesn't have all the preferences of a desktop text editor like Sublime Text but the essentials are there. Editor themes, font selection and size, and tab size and type. There's also find and replace and symbol listing which is handy for larger source code files.

Textastic is working well for me but the one thing that I would like to see a easier management of the files I'm working with. A command pallete like Sublime Text would be a nice addition.

GoCoEdit

GoCoEdit is a new addition to the test. While Textastic I have history with, GoCoEdit is fairly new and I’m still finding my feet with it. It shares many of the same features as Textastic though, so it's easy to get started.

GoCoEdit-and-Working-Copy-together

Like Textastic, you can drag and drop a repository from Working Copy into the app to get started working. Changes to files are marked in Working Copy for you to commit.

Editor themes, font selection and size and tab size and type are supported as well. There's also find and replace functionality as well. I've also found that in GoCoEdit there is a command pallete with limited functionality. You can manipulate text, find and replace text and save a file using this but there's not much else you can do with it.

I must admit, I do prefer working with GoCoEdit over Textastic. Saying that though there isn't much between them and both are more than capable of being all-day text editors if you find you have to work on your iPad Pro for the full day.

There are many things missing from these editors that would be taken for granted in a desktop text editor like Sublime Text but apps like this are still relatively limited in what they can do on a iPad. The most essential features are there though.

Adapting

If there’s one thing I’ve learned from all this is that if you’re going to use an iPad Pro for web development or any other form of work then expect to adapt to a new range of apps. Sure you’re preferred apps might be available on iOS but the interface does require you to adapt to the new environment.

Thankfully iOS is getting there with better features like the split view and drag and drop. Features that we’ve taken for granted in desktop operating systems for years but are only starting to see in operating systems like iOS.

My web development workflow has required some changes for the iPad Pro but it’s nothing drastic and a bit of learning on a new device isn’t a bad thing.

Thanks to Curtis McHale for reaching out to ask about this and giving me that much needed nudge to write.

Exploring alternatives to GitHub

 •  Filed under Posts, Github, Tools, Web Development

I've been a user of GitHub for a long time now. Ever since I started my career in Ruby on Rails I've had a GitHub account.

I'm looking again at alternatives to GitHub mainly out of curiosity. There's been some improvements to GitHub over the last few years and new features are gradually coming out but there are other options out there.

I did move some private repos to BitBucket a few years ago, but due to the lack of any extra features I moved these repos back. BitBucket just didn't have anything of added value that would keep me using it.

I tried GitLab a few months ago but I didn't really give it a fair go. I spent a couple of weeks using but I didn't really dig into it too much. I created my account there again to give it a try. I've been using it now for a week and I've moved a number of private repos over from GitHub. The nice thing is that as well as my repo GitLab has moved over my issue list for each repo. Another thing I don't have to worry about moving it across.

It's still early days to make a final decision on this but I've been impressed with not only what GitLab does at the moment, but the pace in which they are releasing new features.

The best thing and worst thing about GitHub is its community size. A lot of developers use only GitHub for source code hosting and although some people might see this as a good thing, it's like saying that Facebook is the only social network platform out there. Yes, there are a lot of people using GitHub but there are alternatives to it and I'm always willing to explore the alternatives to any development tool that I use.

Once I've spent another few months using GitLab I'll probably have a final decision on where I'll be hosting the bulk of source code. I won't be closing down my GitHub account if I do decide to use GitLab for hosting my source code. I still need a GitHub account for client work, but that's all it will be used for.

Scaling Back

 •  Filed under Posts, Tools, Web Development

For a long time I've wrestled with a number of different terminal apps and tools in the hope of improving my productivity at the command line. Initially I used iTerm2, a terminal emulator for macOS, as my preferred terminal app. Then I also started using tmux, a terminal multiplexer, on top of that. Then came along Vim, the open source text editor, and I started using that as well.

This was the first time in a long time that I had started using all three again. The benefit of using this combination of tools is that I could run both my command line and text editor within a single app and very rarely have to switch away from it.

One huge pain point I couldn't get round though was the simple act of copying and pasting text between Vim and other apps. Despite a number of attempts to get it working I've decided to call it a day on this trio of tools.

  • Vim is a great text editor, but to be honest I'm faster coding with Sublime Text or even Atom for that fact. Yes, I use the mouse and yes I want to have features and plugins that don't require me to mess about with command line.
  • tmux is great for managing different command line sessions within a single terminal emulator but I don't think it's a necessity. Lately I've been doing away with split panes and using multiple tabs.
  • Which brings me to iTerm2. As great an application as it is, there's nothing that it offers that I can't get from Apple's own terminal emulator, Terminal.

So I stopped using Vim, tmux and iTerm2 and fell back to using Terminal and Sublime Text.

I've went full circle from starting with the basics, adding more tools to the stack, before reducing the tools I need for the terminal right down to the absolute basics. One app for the terminal and one app for editing source code.

I can see the case for using tools like tmux and Vim. Maybe you spend most of your day in a terminal as a system administrator and you're faster with Vim. Maybe you need to manage multiple servers on a daily basis so splitting panes in tmux suits your line of work. I get it. I understand why these tools exist and why you would use them.

Sometimes though scaling back is just as much a benefit.

Has Web Development Gone To Shit?

 •  Filed under Web Development

There was me thinking I was absolutely bonkers for not falling head over heels in love with the current trend towards towards JS web frameworks.

The web (specifically the Javascript/Node community) has created some of the most complicated, convoluted, over engineered tools ever conceived.

The Sad State of Web Development by Drew Hamlett

I do like Drew's advice for web applications that have one or two pages with a complex user-interface.

So my advice is to use Rails Django, Play Framework, or Phoenix to develop most of the app, because they help you with most of the boilerplate stuff, and bring in the flavor of the month on a page that needs it. So when the next flavor of the month comes out you’re entire app is not knee deep in the last flavor of the month. You can just re write that one page.

The Sad State of Web Development by Drew Hamlett

How to Run Cheaters with Pow

 •  Filed under Daily Post, Web Development

Brett Terpstra released a new version of his Cheaters cheat sheet system. Brett recommends two options to get this running. The first is using the Automator application in OSX and the second is using the Fluid app.

The one change I wanted to make was to make Cheaters run as a local Rack web application with Pow rather than from the already installed Apache instance. It's easy to do.

1. Create a Gemfile

Create a Gemfile within the root of the Cheaters source and include the Rack gem:

gem 'rack'

Jump back to the command line and run the bundle command to install this gem.

2. Create the Rack App

Next create the Rack file that will serve all the pages and assets from the Cheaters source. I've used this same code for lots of Rack applications.

require 'rack'

$stdout.sync = true

use Rack::Static,
  :urls => ["/css", "/js", "/images", "/cheatsheets"],
  :root => "."

run lambda { |env|
[
  200,
  {
    'Content-Type'  => 'text/html',
    'Cache-Control' => 'public, max-age=86400'
  },
  File.open('index.html', File::RDONLY)
]}

Put this in the root of the Cheaters source.

3. Symlink Cheaters

Now I'm assuming that you have Pow installed already. With Pow installed, change to the pow directory and symlink your Cheaters directory:

cd ~/.pow && ln -s /path/to/cheaters

I also use an app called Anvil that gives me access to my running web applications in Pow from the menubar. This can also create the symlink for you if the terminal is too scary.

Done!

That's it. Now if you visit http://cheaters.dev, you'll find the Cheaters page. The reason I prefer this is that I already have a number of application running locally that I like to use, so running it from the browser is fine with me.