Unfashionably still an Atom editor fan

I’ve loved the idea of the Atom editor since I saw the initial announcement video three years ago:

I used it on and off as a text editor since it was released. Sure, it was sluggish, but I didn’t think too much of it. I used Atom for a text-based productivity system a couple years ago, when I couldn’t find a cross-platform task management system I liked. At some point, I decided to try something a little more responsive, and lightweight.

All the cool kids seem to be using Visual Studio Code, and they love it. There’s certainly a lot to like about Microsoft’s (mostly) open source code editor. It’s lightweight, extensible through a range of really good extensions, it’s cross-platform, and free.

I used it for a while, and enjoyed it. As a newbie coder, it gives me a lot of feedback as I poke around at my coding projects. This can be really helpful, for sure. That’s probably one of the reasons I used VS Code for as long as I did (and why I still have it installed on my laptop). Of course, another reason why I used it is that a number of developers I follow have raved about it.

I initially moved off VS Code, and returned to Atom earlier this year when I started using a more powerful MacBook Pro, and felt drawn back to Atom for some reason. Part of the reason was that a Markdown extension I relied on in VS Code stopped working for me (at least when I used it in conjunction with Alfred.app that I use heavily for my work).

When I came back to Atom, I noticed how well some of the packages I installed seemed to fit into how I worked. The Markdown Writer package, for one, has become one of my favourite packages, just because it makes it easier for me to write in Markdown.

There was certainly a point where I was concerned about Atom’s ongoing development, and how seemingly simple issues didn’t appear to be addressed. I received some good feedback on this, and moved on.

One of my colleagues recommended Sublime Text, so I spent some time testing it out. I love how quickly it starts up, how similar it is to Atom (well, more the other way round). At the same time, I’m not sure I can justify paying the cost for Sublime Text because Atom does want I want to do, with less of the fiddling I need to do to Sublime Text to configure it for how I like to work (mostly keybindings, and Markdown support).

It’s not that Sublime Text isn’t worth the \$80 license fee, it really is (and I agree with paying for good quality software). Even though it took me a few weeks to configure it to work pretty well for me, there are little features that I absolutely love. One little one that I discovered is how it automatically closes HTML tags when I start typing closing tags. These little things are awesome, and bring a little more joy to my day.

In the meantime, Atom has been improving with each release. Sure, it doesn’t have all the tips and feedback that VS Code, and it loads a little slower (although not as much as it used to). I don’t mind that as much actually. I stick with Atom because it works for me.

It fits into how I write Markdown, works well enough for me when I switch over to CSS, HTML, Python, shell scripts, JavaScript, and so on. On those occasions when I need extra help, I may dip back into VS Code, or give Sublime Text another go.

I’m also just figuring out how to “hack” this “hackable text editor for the 21st Century”, and I really enjoy this sort of freedom with my text editor. There’s still so much I can learn about how to use my editor more effectively. Another colleague pointed out a really cool Emmet feature that just blew my mind.

So, in a time when everyone seems to be flocking to VS Code, I thought I’d add my vote for Atom. I’m still a fan, thanks GitHub!

Featured image by Luca Bravo

Creating good through open source

I really like videos like this:

Open source as a way of doing things has such amazing potential to make our world so much better.

Watching videos like this tend to prompt me to revisit my calendar and try find regular blocks of time I can dedicate to my dusty coding projects.

Scientific papers shouldn’t be published as PDFs

I enjoyed James Somers’ article in the Atlantic titled “The Scientific Paper Is Obsolete” about how the standard format for scientific papers, namely PDF, is no longer the appropriate format for such data-intensive work.

This is, of course, the whole problem of scientific communication in a nutshell: Scientific results today are as often as not found with the help of computers. That’s because the ideas are complex, dynamic, hard to grab ahold of in your mind’s eye. And yet by far the most popular tool we have for communicating these results is the PDF—literally a simulation of a piece of paper. Maybe we can do better.

The article recounts the history of Wolfram’s Wolfram Mathematica notebook model, and the rise of Jupyter notebooks as an open source alternative that’s also rising to prominence in the space.

I love the idea of more open, more dynamic formats for sharing knowledge, capturing ideas, and promoting access to knowledge.

My Summer project is to finish an initial version of my Practice Math site for our kids. I’ve hit a bit of a snag with fractions, but the functionality for whole numbers is almost ready.

The next step is to create a web site for the project so our kids can use the app through their browsers, rather than using the command line (somehow, I don’t think a CLI interface will grab our kids).

My plan was to learn Django, and use that to create a front-end for my Python back-end. I decided to follow along with Brad Traversy to help me learn how to create a basic Django app. It was a little trickier than I expected, and I hit a snag with my database configuration.

I then thought I’d take a look at Flask, and see if that would be a little easier for me to grok. I noticed that Corey Schafer has a Flask tutorial series where you build a basic blog with Python and Flask, so I decided to work through Schafer’s tutorial videos.

This has proven to be a terrific idea. Schafer’s tutorials are detailed, and really clear. There are times when he speeds up a little but, for the most part, I can follow along pretty comfortably, and understand what he’s doing.

Even though the goal of Schafer’s series is to build a blog, it covers a range of topics that I can incorporate into Practice Math down the line. It’s really an awesome introduction to building web sites with Flask, and well worth the time.

Not only does Schafer take you through the process, step-by-step, but he also provides links to snapshots of his code at each step of the process, along with useful code snippets in his GitHub repos.

You probably need about an hour for each episode. I binged for most of today (I’m on vacation this week), and worked through about four or five videos.

If you’re interested in Corey Schafer, listen to this TalkPython interview with him:

On a related, side note, working through this tutorial series just reinforces how glad I am that I returned to Python to start learning it (again). I still have a long way to go, but it feels like I’m picking up bits of it easier than I did with JavaScript.

I’ll return to JavaScript, for sure (you can’t really ignore JavaScript these days). For now, though, I love all the things I’m learning to do with Python.

Featured image by Sharon McCutcheon

Practice Math – the Python Edition

One of my projects this Summer is to create a working version of my Practice Math project. The goal of this project is to create a site that my kids can use to practice their math.

The idea was to create a simple site that would randomly generate math equations that kids could use to practice addition, subtraction, multiplication, and division. To do this, the site would need to have the following functions, at least in the first phase of my project:

1. Randomly generate two numbers, and a math operator to create an equation;
2. Evaluate the solution to the equation;
3. Prompt the child to offer an answer to the equation;
4. Compare the child’s answer with the actual solution, and give feedback;
5. Make sure that equations don’t produce negative solutions (our kids haven’t really learned how to work with numbers less than zero); and
6. Round answers to two decimal places (it can be more than this, I just picked two decimal places for now).

Version 1 – the Javascript Edition

My initial version of the project was based on Javascript. You can find that one here, on GitHub. I wasn’t able to make much progress beyond randomly generating the numbers and math operators that would be used in equations.

I hadn’t worked out how to evaluate the randomly generated numbers, more move much beyond point two in my list of features. I’m certain it’s possible, I just hadn’t worked it out yet.

Version 2 – the Python Edition

I recently decided to return to learning Python. I last attempted to learn Python about a year and a half ago. At the time, I was learning Python 2.7.x. I didn’t move beyond loops at the time.

This time, I decided to start with Python 3.x, which is the current version. I’ve been learning when I have time, and I really like the language. I decided to revisit my Practice Math project and create a Python version to help me learn the language.

I finally sat down this morning, and worked on a script that does all six of the things I want it to do. I’ve published my code on GitHub, here. Here it is in action:

I can’t take credit for what you see there, not entirely. I borrowed pretty heavily from a few sources to produce the version you see there:

Cory Kramer’s solution (the third one in this list) was particularly helpful because it helped me split my code into disparate functions. This makes the script a lot easier to read, and tweak.

My current code still has some test stuff in it. For example, the script current prints the two generated numbers, the operator, and the solution so I can check that it’s all working properly:

 print("\nThis is for troubleshooting purposes only:") print(num1) # For testing print(num2) # For testing print(op) # For testing print("\nWhat is {} {} {}? > ".format(num1, op, num2)) solution = round(eval(f"{num1} {op} {num2}"), 2) print(solution) # For testing 

Next steps

The next step is to create a web interface for this. A command line version is fine to play around with, but for this to be useful, it needs to be a web site. I haven’t worked out how to add a Javascript front-end to this (I believe it’s possible, I have no idea how to do it, though).

What I’ll rather do, though, is use a Python web framework like Django to create a front end for the site. I’m really keen to learn how to do that, partly because I want to port my Modiin Bus project over to Python too at some point (I discovered that the transit data that I’d like to use is available through Python APIs).

At the same time, I also intend figuring out how to represent fractions in the web interface. I know that’s it’s possible to use Javascript to represent fractions on a web page using options such as math.js and MathJax. I’ll look for equivalent options for Python/Django.

There are also a couple niggling issues about the current version that I’d like to resolve too. These likely exist because I’m still very much a Python newbie.

I’m sure there are other improvements I could make to how the script accepts, and processes input from users. I’ll figure that stuff out as I go. For now, I’m pretty please that this core script seems to be working.

My idea of a good time: coding on a Linux computer

Lately my idea of fun has been firmly rooted in coding, and playing around with Linux.

We’re planning to buy our son a new Linux PC after passing his (and before him, my) old Linux PC to our daughter.

I’m very tempted to extend my loan of my personal MacBook Air to him, and but myself a new laptop to install Linux on, and use that to explore what’s possibly my latest midlife crisis.

Canonical’s Ubuntu seems to command a lot of mindshare when it comes to desktop Linux, so that was my next stop. I went through the same paces: download to a USB stick, boot up to the “Live” version of Ubuntu 18.04 (which includes 5 years of security patches and updates), have a look around, click “Install.” Ubuntu presented me with several options for partitioning the internal SSD, including blasting the entire drive. Tempting! I was feeling lucky so I took the plunge.

Raising brave, imperfect daughters, and teaching them to code

Last week I came across a tweet sharing Reshma Saujani’s TED talk, titled “Teach girls bravery, not perfection“. I immediately bookmarked it to watch with my daughter (and tweeted my plan to do that).

Saujani replied to my tweet, and asked me to let her know what my daughter thought of the talk.

So, I watched the talk on Saturday morning with my 7 year old (along with my son). Afterwards, I asked her what she thought about what Saujani said about how important it is to be brave, rather than being perfect, and how the quest for perfection is so self-defeating.

My daughter said she liked the video. I asked her to elaborate, and she commented on this talk has inspired her to try to learn to code again. She said that she stopped trying the first time around because she kept making mistakes.

I noticed this when I introduced her to coding on Code.org last year. She started off really excited to see what she could create after watching me learn front-end web development for most of last year. But she soon gave up when the exercises became trickier and she found herself making mistakes.

Since watching the talk, she’s been asking me when she can get back to learning to code. It also helps that my son has also returned to learning to code after seeing me return to Python (I’ve started at the beginning with Python 3).

Now all I need to do is pick a learning platform for her to learn with. So far, Code.org and Scratch look like good options for her.

Photo by Jelleke Vanooteghem on Unsplash

The life of a coder in gifs

The life of a coder/developer is both a wonderful and immensely frustrating experience. The scales tip in both directions, usually several times a day.

Today was no exception. I’ve been stuck on something for the last few days. My code should have been working, but it didn’t. If I had hair to spare, I’d probably have torn some of it out in frustration.

Of course, as these things tend to go, I found the reason why my code wasn’t working. It was a typo. A single letter that shouldn’t have been there.

My sense of relief is somewhat moderated by my amazement at how I missed it.

But, on the other hand, I found the bug! Now on to the next new code and the next bug.