The Dopefly Tech Blog

Coding on a Chromebook

posted under category: IDEs and tools on February 13, 2021 by Nathan

I mentioned how I’m teaching a high school coding class at our home school co-op. At the beginning of the 2020/2021 school year, I specified that students need a Windows laptop, or a Mac if there was no other option. I don’t like to support Apple devices. I specified that no Chromebooks would be allowed in the classroom. It was the right choice last August, but this next school year, I’m going to let Chromebooks in.

Every week I write up a new presentation in Google Slides, and present it to the class on my Chromebook. Between Google Docs for the slides and GitHub for the files, I have access to everything I need across all of my devices. But what about coding on the Chromebook? Aren’t Chromebooks underpowered laptops with nothing but a browser? How’s the coding experience, you ask? I’m so glad you did!

First, you should know that every Chrome OS device is essentially three things:

1. A Google Chrome web browser device - the classic foundation and namesake it’s had since 2011
2. An Android tablet with full access to the Google Play store and most Android apps and games, in fairly performant windowed environment, since 2016
3. A Linux laptop with a Debian terminal that grants full access to apt-get anything you want, since 2018

There are some really great in-browser IDEs, but I like to keep things local and offline, cutting my choices down significantly. There aren’t any great Android-based IDEs that I’ve seen. But wouldn’t you just want to use everyone’s favorite coding tool? That’s right, I want VSCode on my Chromebook. And guess what? It’s become really easy to do this!

The steps have become essentially the same as they would be on any other operating system. Visit the VSCode website, click the giant download button, then double-click the installer. This was much harder only a few months ago! I was taken back when I had the chance to install it on a new device recently. It’s seamless. I also double-checked that it added VSCode as a known repository for the integrated package manager so that upgrading can be done with sudo apt-get update && sudo apt-get upgrade -y. Or of course you can go download the new version and run the installer again. That’s not quite as seamless as it is on Windows, but it’s not bad at all.

At the start of the 2020 schoolyear, I had an outdated Acer R11 Chromebook with a flimsy Celeron CPU. It performed fine, but the lower resolution 11 inch screen was pretty small for the task at hand, and starting VSCode was a commitment.

This year I invested my incredible teaching profits (that’s a joke!) when I found that Lenovo’s Chromebook line finally includes the incredibly affordable and powerful 10th gen i3 model with 8GB of memory. It’s a steal at $440. I’m not trying to advertise, but I do have an affiliate link to look at it on Amazon because it brings me some happiness and maybe you’d like to check it out. Something amazing about this device is that it launches VSCode in about 1 second - there’s no delay. It’s faster than my i7 work laptop. It has plenty of power for this job!

So my Chromebook has VSCode. What next?

Extensions! They all work. Everything I throw at it works perfectly. I’m not missing anything in this department.

Debugging! Works perfectly. I’ve only tried debugging JavaScript, web pages, and C# code, maybe Python last year, and they are every bit as capable as anywhere else.

Coding! Duh. It definitely works.

Anything wrong?

Only one thing doesn’t work for me. It’s the standard Chromebook keyboard. Not even the physical keys, this Lenovo has good feel for such a quiet sound. My gripes are about the keyboard on Chrome OS devices, namely these complaints -

• The lack of a 6-key insert-delete, home-end, pageup-pagedown block is annoying enough. I miss that on every notebook keyboard though. The problem is that these keys literally don’t exist. On a Windows laptop, I can at least find these keys. They’re often hidden behind a function control key, but they are there. There’s no chance to find them on Chrome hardware.
• No delete key. There is a way to delete - alt+backspace will delete in front of the cursor, while the standard backspace key only deletes what is behind the cursor. If you ever want to delete a file, you are forced to make the two-finger-salute.
• Alt + Click is a right-click in Chrome OS, instead of the standard multi-cursor selection combo in VSCode. I suppose this is configurable so I can change it to the Ctrl key, but it’s very annoying.

Of course all of that can be ignored if you plug in an external keyboard. I’m not carrying a keyboard around in my bag, or over to the couch, so I just have to live with the pain.

Wrap-up

Coding on Chrome OS is great with VSCode, and it’s a very workable solution. Get a powerful processor, no Celerons or Pentium chips, and get plenty of memory. If you’re settling down for a long coding session. bring an external keyboard and mouse just like you would want with any laptop. Now that VSCode works flawlessly, the gates are open wide!

Version Control Software Isn't Just For Code

posted under category: IDEs and tools on March 17, 2016 by Nathan

Many years ago I read an article where someone put their linux-os home directory in source control - probably CVS at the time, this was a while back. He’d had it running that way for a long time, too, and could roll-back his desktop to last week, checkout the latest version on any new PC, throw away destructive changes, and save & commit beneficial changes. It got me thinking. Version control software isn’t just for code, it’s for any file.

Years ago, when playing Minecraft server admin for my kids, I came up with the idea to put their Minecraft world into Git. We could check in changes nightly, which would allow us to blow everything up and just roll back, or invite a destructive friend over and then undo everything he did. It also gave us the ability to clone the server into a local world when the server was too slow, play locally, then push progress back up to the shared server. And then there’s branching - one child could go out and do stuff in another part of the infinitely generated world, then merge changes back on to the server if it worked out, or drop the branch if it didn’t. It’s brilliant. It ended up a little more work than anyone wanted to do, but the idea was there.

Recently, when researching backup software, I found two real categories of solutions for backups:

• Your backup is just a copy of your files on another server or drive, with no historical data integrity
• Your backup software in a database somewhere, but you have to use specialized software to retrieve your files

After searching for a while, I found bup. It’s actually based on Git, which gives you the best of both worlds for backup software - a live, local copy of files that you can browse like any file, plus versioned incremental backups that you need a special client to retrieve. You can host it on a file share, and effectively, git-clone (technically bup-clone) to add another backup server.

I’ve no doubt that there are a million other potential uses, too. Version control software is not just for programmers and code!

I am switching to Git

posted under category: IDEs and tools on July 27, 2011 by Nathan

I've been a pretty big fan of revision control software since I started hearing about it. It's crazy that I was a developer for so many years before I heard about it at all. I guess that's what I get for keeping my nose to the ground (note to self: write about being a new developer and getting connected).

I thought I had skipped the entire CVS generation until I joined a very large, almost 100 year old company. Boeing loves CVS, I guess just because it's reliable and was around when they set up their servers. My CVS server is doing fine, but it's slated for a migration to a new data center, possibly facing an end-of-life soon; the guy who maintained it left the company over a year ago. Naturally, I looked into Subversion. There is an enterprise hosting group that hosts SVN over SSH, which means SSH software, managing keystores, telnetting, all kinds of things that I am not a fan of. I had it working, just barely, only through Tortoise and not Eclipse, but it was hard and I would have to help all my teammates get it to work, too. They're smart, but this setup is harder than I want to work. I would have migrated to SVN, but they made it way, way too hard.

The great news is that they do make Git available to me (if I know where to look [Boeing has a strict software installation policy {I can only install the software they give me <recursive parentheses are fun «sometimes»>}]).

I had big initial troubles with understanding the concepts of Git. Everyone who switches has the same trouble. Expect it and don't let it get you down. Git uses a lot of the same words with different meanings, and the need to branch and manage branches is much more prevalent. I found EGit (the Git plugin for Eclipse) completely confusing and stupid. The command line was out, come on, this is 2011. Even TortoiseGit was acting broken. I needed help, and lots of it.

Thankfully, I got to attend two different hour-long Git sessions with Tim Cunningham, who pointed out some other resources. I watched a few other videos, the best was probably Jenny Donnelly's Introduction to Git from Yahoo. Then I read a lot, practiced some, and finally, here I am - switching!

I came to terms with EGit and TortoiseGit - they both make sense now and they work great. I use the Git Bash shell now and I don't even feel weird about it. I keep a cheatsheet on my wall and refer to it regularly.

It's at this point that I can look for the real benefits, to see if this little project pays off.

My Git architecture is very simple and based on what Tim showed off. It's simple file shares across the network. At first it sounded awful, but in reality this works like a charm. The shares are backed up. I control file access. I just have to enforce a couple strict pushing practices and everything is gravy.

I think what I most like about this setup with Git is that it inverses the control (IoC! [kind of]) of my source control software. Where before I needed a server, IT hardware support and had one repository, now I make and control the repository when and where I want it. Where before committing to a subversion repo on a flash drive seemed like a half-broken hack and it would never sync to a remote server, now it's a way to win easily. It feels liberating. It's really cool. This developer's tool doesn't need a server anymore. It just needs a capable developer. It's developer's software for developers, and I love it.

As I've progressed with Git, I have branched and merged and pushed and rebased and stashed pulled and diffed. Some of it has been a big challenge, like putting current work aside to get out a quick fix, I had to learn to stash, then make remote branches, and so on. It's tough, but thanks to google's index of stackoverflow, I'm making great progress!

In summary, Git is good, you should learn about it, give it a try and have patience.

Start Eclipse faster with -initialize

posted under category: IDEs and tools on April 10, 2009 by Nathan

There was some good discussion today on the CFEclipse Users email list about getting Eclipse to start up faster, and I offered this suggestion:

Run this command when you log in to your workstation:

eclipse -initialize

Initializes the configuration being run. All runtime related data structures and caches are refreshed. Handy with shared installs: running Eclipse once with this option from an account with write privileges will improve startup performance.