Although I have a degree in computer science and teach Microsoft programming, coding is not my day job. As a result, I go through relatively frequent periods when I’m not writing a single line of code, and then, when I get some free time, I try to jump back in.
Mostly, my programming now is supporting an open source donation system, and I do it both because I like to code and because I want to keep my chops up. It’s easy to lose touch with a skill like programming, so making sure you do some of it regularly is one way to stay reasonably fresh.
My normal workflow involves jumping between three main computers: My desktop, a machine by my couch, and my laptop. With cloud-based applications, this isn’t a problem. But with coding, it can be a pain.
To explain, let’s jump back in time. Back in the day, email users used to keep their email on their local computers. Outlook used PST files, and Eudora (if I remember correctly) used box files. The POP3 protocol was designed to allow users to connect into a mail server and download their messages.
This mean that your mail lived on one machine. If you were on another machine, you couldn’t see your mail store. IMAP sort of fixed that, as did Exchange. But many users were still POP3 users and did not have a central email repository.
Cloud-based email services like Gmail changed all that. Most of us, now, use a cloud-based email service and login through our browsers. We can look at our email from any machine (or phone) that has access to the cloud. This is the whole SaaS model. Whether its email like Gmail, CRM like Salesforce, accounting like Quickbooks online, to-do list management like Todoist, or big ERP systems like those offered by SAP, cloud-based SaaS services make mobile anywhere access a breeze.
Oddly enough, programming systems are somewhat behind the curve. There are certainly cloud-based programming environments like Amazon’s Cloud9, CodeAnywhere, CodeEnvy, and Visual Studio, but they’re far from perfect — at least for some coding needs.
For me, cloud-based coding is the holy grail. I’ve long wanted to be able to jump from system to system, and even anywhere there’s a browser, to be able to code. My current project lives in the cloud, has to be tested in the cloud, so why shouldn’t I be able to code it in the cloud?
The thing is, I could. There are a ton of exceptional cloud-based code editors. Think of code editors as word processors, but instead of fancy formatting, they manage the unique aspects of the programming language and environment you’re working in.
They provide code completion (finishing out an object or function name), syntax highlighting (automatically different parts of code in different colors), refactoring (renaming elements of code throughout a project), code-folding (so you can see the big picture), and code reformatting (so the editor does the work of making it all pretty and readable).
These are huge helps for programmers. But there’s another key feature that I, at least, find absolutely essential: A symbolic debugger. A symbolic debugger is a tool that lets you set breakpoints in your code as it runs, examine the values of variables and objects, change those values on the fly, and more. It’s, essentially, the test probe of programming work.
There are two main debugging engines for PHP: Xdebug and Zend. When they work, they’re both really excellent. But even in the best of times, they’re hard to setup and very fiddly. They have to execute code both locally and remotely, sometimes they have to set up an SSH channel to communicate debugging info, and they often require lots of configuration tweaks that are unique to every coding environment and every host.
CLOUD-BASED IDES (AND THEIR LIMITATIONS)
Every six months or so, I take a run at the various cloud coding environments to see if they finally support PHP debugging. And every six months or so, I come away disappointed.
CodeAnywhere has a number of wonderful features, including letting you store your source code in Google Drive or Dropbox. But it has absolutely no debugging support for PHP. It understands PHP syntax, but if you want to debug something, you have to drop in the equivalent of print statements throughout your code. It’s not optimal at all.
I tried to get CodeEnvy to work. CodeEnvy is based on Eclipse Che, a cloud-based version of the very powerful Eclipse IDE (interactive development environment). CodeEnvy actually has documentation on getting Zend and Xdebug working. That’s a rarity.
But after about four hours trying to get their default stacks to spin up with all the right configurations and work, I gave up. While some developers tune their development environments over the course of months or years, I need to be able to get in and get out. Clearly, while Eclipse and CodeEnvy are powerful, they’re too time-consuming to solve the problem.
Then I spent quite a while with AWS Cloud9. Amazon acquired Cloud9 in 2016. I thought this would be ideal, since AWS is AWS. I liked the idea of quick integration with S3, LightSail, and all the other AWS services. Unfortunately, I couldn’t get debugging PHP to work.
I did find an April 2018 post from an AWS guy that said, and I quote, “That should be possible, though none of us at Cloud9 have experience with doing this.” He pointed users to a six-year-old Stack Overflow note postulating how to do remote debugging, but it said nothing about making it work with the native Cloud9 EC2 image.
While both Microsoft and Google have cloud development offerings, neither seems to have an answer for PHP.
WHAT ABOUT A CLOUD-BASED DESKTOP?
I thought about setting up a VDI account on Azure or AWS. That would have worked in that I could remote connect into one of those accounts, keep the desktop and configuration on the cloud, and remote desktop from almost any browser.
The thing was, I didn’t want to manage another desktop. Using a Windows-based setup is easiest, at least for me. But WordPress is fussy on Windows, so I’d have to set up Windows, an IDE on the cloud Windows install, and then set up remote debugging to a Linux box hosting my software.
Setting up a virtual Linux host in the cloud is cake, but getting a remote desktop configuration is a bit more work. It’s doable, but then I’d be switching to a Linux UI in a browser window to do all my coding. Meh.
It was when I considered setting up a remote Mac desktop in the cloud using a service like MacInCloud and MacStadium that I realized the idea of a cloud-based remote desktop is dumb. First, the Mac services are either underpowered or very expensive.
But more to the point was this: If I were going to rent someone else’s ancient Mac mini colocated in a cloud somewhere, why wouldn’t I just put one of my own Mac mini units online, connect to it via a remote desktop, and go to town? There’s no reason at all, except I’ve done that already before and it was suboptimal.
Because I’ve been down that road before, I decided not to go there again. I really do want a true cloud-based IDE environment without having to sysadmin another computer, virtual or not.
This article is shared by www.itechscripts.com | A leading resource of inspired clone scripts. It offers hundreds of popular scripts that are used by thousands of small and medium enterprises.