Do you find yourself fighting your editor? The common text editors of today work quite well as long you work they way they want you to. Yet, when you stray from their paradigm, even when they seem to offer infinite flexibility, it can be a chore to get even simple things done. What is a developer to do?
Meet the Problem
When you run up against frustration, it helps to define the problem. In my case, the problem was less about the editor, and more about how it integrated into my workflow. I’m more of a remote developer, leveraging ftp and shares as apposed to local file systems. For me, an integrated file browser works better than stand alone windows and applications.
My desire to use remote folders as if they were local was my biggest hang-up. The editors I tried, including the most popular ones, wanted to open up a new window that you couldn’t dock. On smaller screens, like a laptop, this became a painful as windows stacked up and slowed down how I worked. I don’t mind switching programs on principle, I just prefer a less cluttered interface.
As my search stretched on I found myself spending more times finding an editor than working on code. This wasn’t where I wanted to be. Worse, as I bounced between different programs I kept finding nuanced differences that made other things worse. I was stuck.
Don’t Box Me In
Coming to the conclusion I need to find another solution, I focused on making remote files look local. Most editors seemed to embrace the local file system with aplomb. Knowing this, I began researching with high hopes. I even found a solution that my hosting company supported, WebDav. Unfortunately, it proved to be a false hope.
WebDav, as good as looked on the surface, began to show flaws during use. Let me tick them off:
- Required reconnecting on reboot
- Wasn’t as secure
- Added hidden files on Mac
- Saving overwrote permissions
Not exactly what I hoped for. The last item caused me the most hassle as it required me to pop into a terminal window to fix permissions.
It was becoming clear that trying to work around the editor wasn’t the right solution. What I needed to do was focus on the outcome, and less on the solution. The key was my desire to develop remotely, something the solutions I was finding didn’t want to do.
Problem, Meet Solution
When it finally clicked that a local client might not be the answer, I did what I should have done in the first place. I broadened my search and started to embrace cloud solutions. It took less than an hour of research to realize what I needed was already solved. Not just by one, but many cloud providers. Now my problem was picking one!
As often happens when you remove constraints, my outlook changed and with it, my needs. I started to expand my requirements beyond a good editor with integrated sftp. My wants now included:
- Code highlighting
- Perl support
- Drag and drop
- Shell access
- Access to cloud storage
The list kept growing and, to my surprise, the vendors kept meeting the challenge.
Taking the plunge on a solution, I landed with Codeanywhere. Although it met my needs, and I highly recommend it, I don’t want to bias you. There are plenty of other cloud based solutions and your needs will differ from mine. Do your research, like I did, and decide what makes sense for you.
Relishing the Change
Now that I’ve been coding in the cloud for a couple of months, I have to say it did a whole lot more than just solve my problem. I’ve condensed my workflow, editing and testing code from the familiarity of my browser. I’m no longer tied to an ecosystem either, a freedom I welcome even if I wasn’t looking for it.
I also now have options. There are features I still haven’t explored that can only help to improve my workflow. It is nice to know that I can leverage other systems and devices should I find the need. I haven’t tried CodeAnywhere’s iPad application yet, but I’m sure it works fine. I’ve even been asking myself if I could live with a more limited device like a ChromeBook. The possibilities feel endless.
It is with a bit of irony that I landed on the cloud solution last. I’ve been saying for years that applications should be browser first. All my projects at work started with this approach. To think that for my own development I was still stuck on using fat clients just shows my own bias. My mind is now open. Is yours?
Image courtesy of Unsplash.