Category Archives: Software Engineering

Applying engineering and architectural design to software development.

Packaging up a Rust Binary for Linux

Posted on by

Prologue

I should of written an update for quite some time. While I’ve been experimenting with marketing analytics, learning about data science, business development, doing DevOps with GitLab CI and various other things, I wanted to write up my learning when I had a chance to internalize everything. However what made me decide to write an update is this tweet from Chris Krycho. Chris runs the amazing New Rustacean podcast, which is a must listen for anyone interested in learning about programming in Rust.

How does one package a Rust app?

Chris asked about finding a good way to distribute Rust binaries across Linux distros:

Interestingly enough, I recently figured out how to package a small Rust CLI utility that I’m working on. My response was:

This post elaborates on what I meant with my reply.

Building snap packages using snapcraft

The fine folks at Canonical (the makers of Ubuntu Linux), have created something called snap packages. These packages and associated package manager help developers distribute applications (desktop, cloud, etc.) in a safe, isolated manner. I currently have slack installed this way. snaps isolate apps by having the package maintainer declare the capabilities an app requires (network access, access to system files, the GPU, home directory, etc.), and then ensuring the apps can not escape this sandbox.

Basic Setup

Getting setup with packaging a Rust crate was not too hard:

  1. Install snapcraft: sudo snap install snapcraft --classic
  2. Create a snap template inside your crate project: snap init
  3. Edit the generated snap/snapcraft.yml as per the documentation.
  4. Build the snap using snapcraft.
  5. Install the resulting snap with sudo snap install my-cool-rust-bin_x.y.z.snap --devmode --dangerous (this assuming you are experimenting with building a snap)
  6. Add you should be able to distribute your app as a snap now. (See the caveats below.)

Caveats working with snaps

Now there a bunch of caveats when working with snaps. And for my own Rust utility, I found these too taxing and I decided to go with creating a standard Debian package instead. However if I wanted to target multiple distributions and my app didn’t have a very unorthodox setup (my app relies on using the Chrome WebDriver to control a networked device managed by dd-wrt), I would probably have gone with a snap instead:

  • You need to know what capabilities your app needs: file access, network, etc. and you need to declare the appropriate interfaces in your snapcraft.yml
  • Using something other than my local system (be it a Docker based build or using a different base like base18), failed terribly at least for Rust.
  • Whether or not I’d have more success if my base system was the recommended Ubuntu 16.04 and not 18.04 is an outstanding mystery.
  • The snap confinement, even on the much more liberal devmode, works very well. No amount of coaxing on my part, let me use system paths when trying to spawn a process. This could just be me though, as not declaring network access did not block my app.
  • The docs could of been clearer about what was the latest recommended approach. (Still way clearer than the documentation for creating a DEB or RPM from scratch.)
  • Knowing which libraries (for the type of base system) your app needs takes a bit of experimentation. (e.g. I needed libssl1.0 for some builds and libssl1.1)
  • I have no idea how the classical confinement should work, and it is not recommended either way.

The end result for me was a working snap package, but an app that would not work when called from an installed snap. However I think snap packages are probably the way to go moving forward (or a similar format like flatpak). Since I only plan on targeting local Ubuntu 18.04 installs, I ended up creating a Debian package instead.

Building a Debian package with Cargo

I found a nice utility for creating a deb out of a Rust crate, called cargo-deb. After installing the crate with cargo: cargo install cargo-deb, I simply ran cargo deb and I was done. cargo-deb looked into my Cargo.toml for the metadata, ran a build and a few moments later I was the proud owner of a Debian package. Since my app relies on the chromium-browser and chromium-chromedriver packages, I added a small section in my Cargo.toml as so:

[package.metadata.deb]
depends = "$auto, chromium-browser, chromium-chromedriver"

The $auto is something that the Debian packaging mechanism needs, and that is the comma separated format that DEBs use.

Building a RPM from a DEB package

Now this the part that I didn’t do this time around. However I figured out how to create RPM packages from DEB packages a few months ago. The trick is to use the alien utility to create a RPM out of a DEB:

sudo alien --to-rpm --scripts --verbose my-cool-rust-bin.deb

For the record, I did not try to improve or debug the resulting RPM. (This entire effort was for a product that failed to launch.) However as part of my tests I was able install it and run it from on CentOS VM.

Epilogue

Anyways, I would recommend the cargo-deb and alien approach, if you are not planning to distribute a Rust app across a multitude of Linux distros. I would recommend dipping into snap if you plan on distributing something more commercial and wide-spread like a slack or kubectl. And I hope that helps you on your Rust app packaging for Linux journey!

See You at PyCon US 2016!

Posted on by

If you’re wondering why I’ve been so quiet these past few weeks, it is because I’ve been busy preparing to go to PyCon US in Portland this year!

I am very excited not only to be attending, but I will be giving a talk at PyCon US this year! I will be talking about Dockerizing Python microservices, and some of the lessons we’ve learned along the way at work. My talk will be on the first day (Monday May 30th) at 3:15-3:45 PM (PST). Videos of the all PyCon talks should be available a few days after the talk.

Huge thanks to everyone at my workplace, Points, for making this possible for me!

Finally I will be around in Portland for a few days after the sprints as well. I have never been to Portland, so I want to check out some of the sights around there. Let me know via Twitter or email if you want to meetup with me while I’m there. 🙂

Giving a Talk at PyCon Canada 2015

Posted on by

I am super excited to announce that I will be doing a talk at PyCon Canada this year! I will be talking about migrating from using Fabric to deploy my WSGI app (Rookeries) to using a combination of Invoke and Ansible. PyCon Canada will be happening in Toronto at the University of Toronto campus Saturday November 7 to Sunday November 8, 2015. My talk will on the Sunday at 3:45-4:15 PM. Videos of the talks should be available about a day or two after the talk. I look forward to seeing everyone there!

More info on my talk.

Also I plan on being at the Sprints the following Monday as well.

Command-line JSON Formatting with jq

Posted on by

About 2 or 3 months ago, when testing a deployment of a microservice at work
with Eric, our head Ops admin, we were looking at the JSON output of one of
the REST endpoints. Rather than looking at the raw output from curl, I
piped the output through JSON tool in the Python standard library:

$ curl -X GET -s http://rookeries.org/status | python -m json.tool
{
    "app": "rookeries",
    "version": "0.4.9"
}

(I will give you a couple of examples based on calls to Rookeries, rather than
the actual service call, since that API isn’t available publicly yet.)

Eric seeing that suggested I try out a utility that he uses: jq which is
great for formatting and querying JSON.

Installing jq

jq is a utility in C, and fortunately there are binary packages available for
it in the latest Ubuntu LTS (14.10). Installing it via aptitude (or apt-get):

$ sudo aptitude install jq

Pretty Printing JSON

The simplest use case for jq is to simply pretty print JSON output. This is
done by piping the result of a CURL command to jq with the parameter ‘.’:

$ curl -X GET -s http://status.bitbucket.org/api/v2/status.json | jq .
{
  "status": {
    "description": "All Systems Operational",
    "indicator": "none"
  },
  "page": {
    "updated_at": "2015-09-03T08:03:55.275Z",
    "url": "http://status.bitbucket.org",
    "name": "Atlassian Bitbucket",
    "id": "bqlf8qjztdtr"
  }
}

Formatting JSON in jq

It is also possible to format the output of the JSON to display only relevant
information. For instance if I want to find out the status of the components
that make up Bitbucket I can do the following:

$ curl -X GET -s http://status.bitbucket.org/api/v2/components.json | jq .

That however will give me a whole lot of extra data that I might not want. So
instead I might to narrow down and re-format the JSON data to something more
manageable with some jq magic:

$ curl -X GET -s http://status.bitbucket.org/api/v2/components.json | \ 
jq '{src: .page, components: [.components[] | \
    {id: .id, name: .name, status: .status}]}'

{
  "components": [
    {
      "status": "operational",
      "name": "Website",
      "id": "g0lfj4sv2fhf"
    },
    {
      "status": "operational",
      "name": "API",
      "id": "k0x2yw1435v7"
    },
    {
      "status": "operational",
      "name": "SSH",
      "id": "qmh4tj8h5kbn"
    },
    {
      "status": "operational",
      "name": "Git via HTTPS",
      "id": "c1qmcrcbc5zy"
    },
    {
      "status": "operational",
      "name": "Mercurial via HTTPS",
      "id": "vmbzxbbjz05j"
    },
    {
      "status": "operational",
      "name": "Webhooks",
      "id": "rfzky0v13fbp"
    },
    {
      "status": "operational",
      "name": "Source downloads",
      "id": "28h8dvv2qfzw"
    }
  ],
  "src": {
    "updated_at": "2015-09-03T08:03:55.275Z",
    "url": "http://status.bitbucket.org",
    "name": "Atlassian Bitbucket",
    "id": "bqlf8qjztdtr"
  }
}

I won’t explain that particular string in detail. But it will basically
craft a new JSON object, and generate new filtered objects when iterating
over the old array. Overall jq is pretty neat and is extremely fast to work
with.

There is also a Python bindings library for jq. I am considering using it to
help with mapping JSON into Python objects. However I have not played around
with it long enough to know if the extra dependencies are worthwhile or
whether or not it will bring a lot of benefits to Rookeries.

Reference Links

Now a Professional Pythonista at Points!

Posted on by

I have been working for the past month as a Software Development Engineer at Points International.  While my role is not officially as a Python developer, a large portion of my work is building Python applications, services and libraries.  Also I get to develop in Java as well and maintain some very well engineered systems as well, so I get to deal with both worlds.  Even after a month, I am super excited to work at such a cool company and with awesome people.  It really feels like a bit of a dream job, in terms of what technology I get to use (Python, Linux desktops and distributed version control systems, w00t!) and the processes (yes Agile and proper software engineering totally works when done right).

But it is the people within the company that really makes it shine.  I get to be surrounded by smart, savvy, and welcoming coworkers, including a number of important and active Pythonistas that I look up to.  My team is just amazing, supportive, and I feel that in this short time span I’ve become a much better developer thanks to them.  Even on stressful days I feel motivated and excited to come to work and give it my all.  I feel incredibly lucky and fortunate to be at Points. 🙂

Keeping Track of Time – Part 1 – Recognizing the Problem

Posted on by

I have a confession to make.  Like many other software developers, my time estimates are seem to vary from real time.  Yes, giving accurate time estimates are a difficult task, especially ones that are over long extended periods of time.  Add on top of that time seems like an illusion at times, and you have a perfect storm for inaccuracy.  However one of the hallmarks of a good senior developer are good time estimates.  So what to do?

Well you have to fix that problem like any else.  First lets do some research on the problem:

From the looks of it, the problem consists of breaking down a project or a problem into reasonable amounts.  Then one can build time estimates on the design, implementation, integration and testing of the components.  Sounds easy, yes?  Not quite, but that is a skill that can be developed.  How?  Well track the components needed to perform a certain task, measure the time it takes to finish the task and finally do analysis on the results.  Sure you can do this by hand, with nothing more than a pen, paper and stopwatch.  However this is far too tedious and onerus when developing.  Humanity invented and built computers for tasks just like this.  Again after a bit of searching online I found the following tools:

Over the next couple of days and weeks, I will play with each tool and try to figure out which works for me.  Finally I will write about which worked out the best for me overall.

Does Complexity Necessarily Translate Into Capability?

Posted on by

Two months ago I started work as a Java developer at Bluerush Media Group.  Shifting gears back into Java EE/JSP/Servlet and mostly backend work from Android development definitely took a while.  On one hand my work now is hidden behind layers and layers of servers, middleware and other “businessy” systems.  I definitely miss being able to have my work appreciated by many people.  Now only my fellow developers can compliment or complain about my work.  But on the other hand, I enjoy working with tested and tried technologies and platforms.  No more worrying about inconsistencies between devices.  No more fretting about what systems I communicate with.  No more frustrating moments of dealing with performance and optimization issues.  Instead there is more than enough computational power lying around that automation and abstraction become powerful tools to approaching and solving problems.  I feel less guilty about using some crazy library to configure itself, gather the necessary data and build part of the system for me.  In short, as with everything in life there are pros and cons to my work.

Just recently I discovered the joy of using JAXB.  It is mindbogglingly convenient to build entire packages of Java model classes from a single XML schema, and having JAXB handle the serialization and deserialization of Java models into XML and back again.   Using JAXB, some XML configuration files, a TestNG suite and some result data in CSV form, I could build out a pretty sweet and rather involved automated testing setup.  This let me run real stress tests on the application I am working on and letting me flesh out the code much faster and with greater confidence.  Or take the use of dependency injection from Spring or Guice, to help a developer initialize a large number of objects with complicated dependencies without getting lost.  The amount of automation and abstraction in Java EE is simply overwhelming.  However it does come with a price: complexity.  So while using the full power of Java EE and various libraries gives my applications a lot of capability, they also make the applications terribly complex.  It only gets more complex, the more “enterprisey” the application becomes.  There is simply no way I could even build the applications that I do, without having lots of complex tools such as a full-on IDE like Eclipse.

This brings me to the point of my post.  At same time as I delved further into Java EE, I am getting more and more interested in Python and Django.  After playing around a tiny bit with PySide building Qt apps in Python, and looking into Django I am surprised by how terse yet functional Python is.  Yes, Python being a scripted language will never outperform a compiled program (or even byte-code compiled Java app) in terms of performance.  But looking at how much computing power is available and how many more steps it takes to write a Java or other compiled source app… I wonder if programming in something like Python can not be more efficient.  What I am especially curious to find out is if one can build and maintain a large complex web app as one can in Java EE, but in Django and Python.  Basically I am curious of the capability of an app is proportional to its complexity.  Or is this just an illusion from living with a language and platform that lets you easily craft monolithic monsters?  Can one get the same results with good architecture, some smart engineering and a flexible language?

Happy Ada Lovelace Day

Posted on by

Wednesday was Ada Lovelace Day! (UPDATE: Apologies for the late post.)

In a nutshell, March 24 is set aside to promote the achievements of women in IT and software engineering.  And we can start by looking toward the achievements of Ada Lovelace.  Ada Lovelace-the daughter of the famous poet Lord Byron-was the first computer programmer and worked with Charles Babbage on the theoretical underpinnings of computing.  Without her contribution, modern computing probably won’t exist today.

Now I’m not into the whole feminist movement.  I don’t think the movement really represents what the majority women think or want. And the feminist equation of “woman == man” doesn’t make sense.  Neither does any equation that tries to equate one person with another.  All humans should have the right to own their own bodies and not being owned by others.  And I won’t get dragged into a libertarian versus non-libertarian political theoretical debate here.  However I was brought up thinking that women can think as well as men can.  Therefore women can do engineering, mathematics and computing as well as men can.  (<flamebait>Maybe even better.</flamebait>)  So I want to acknowledge in this post, women who I highly regard and who have achieved great things in IT.

@Home: Mom

OK so my mom doesn’t work in IT.  She in fact dislikes computing in general.  We still disagree over the fact that I chose software development as a career.  However I regard her highly and without her work I would of never been able to work as a software developer.  Mom not only brought me into existence, she also taught me.  She as someone with a Masters degree in Civil Engineering, she could of worked on engineering amazing structures. For various she gave that up, to teach and raise me and my brother.  When two public school boards gave up on me ever reading or writing, Mom taught me.  She taught me mathematics and gave me a solid base that carried me well into university level math.  And she always would point out how weird it was that Canada didn’t have as many female engineers as Poland did.  While there are many reasons why that was the case, it was Mom who taught me to believe that women can and should be engineers if that was their calling.  So while she doesn’t work in IT or software development, Mom brought up a pretty decent (IMO) software developer.

@Work: Jennifer Chung, Salina Behera , Safa Siddiqui & Monika Schigel

I am privileged to work with the above ladies at my current workplace, VisionMAX Solutions.  Jennifer and Safa works as developers.  Salina is one of our talented DBAs.  And Monika works in that dark, arcane magical realm known as data modelling.  Not only are they great people to interact with, they also possess a wide body of knowledge.  Jennifer is a whiz at Java and ExtJS, and I often find myself asking her for advice on how to solve various tricky problems.  Monika has a way to cheering people up and I’ve never seen her without a wide grin on her face.  Also she and Tom, our two intrepid data modeller have been initiating me into the dark art of data modelling and the business of retail and mobile telecos.

@University: Katarina Halan & Megan Foote

While studying Computer Science at the University of Toronto, I had the opportunity to study and work with these two incredibly talented ladies.  We helped each other out on assignments.  I can not stress how well they understood the various aspects of computer science.  Also they introduced me to some interesting parts of Japanese culture, namely anime and DDR.

In the Open Source Community

Finally, two ladies that inspire me to get more involved with the open source community as a whole are: Emma Jane Hogbin and Celeste Lyn Paul.  Emma works on creating and managing documentation at various open source projects.  Celeste is a HCI expert who helps make KDE applications have the best user experience of any desktop related project.   I’ve only had the opportunity to meet Emma in person at Ontario Linux Fest 2009.  But Emma, you sure inspired me to look at the various components of documentation.  And yes documentation can be sexy.  I don’t get the ponies though.  Celeste on the other hand inspires me to one day get back into university and work on getting a human-computer interface design.  Her work inspires me to improve the UIs and workflow of any piece of software I am involved with.

To all these ladies, I’d like to personally say thank you.  You made me a better software developer.  And you are an inspiration for all women in or thinking of working in IT and software development.  Thanks!


The Seven Sins of Software “Engineering”

Posted on by

On Monday, my class discussed about using software “engineer”for software writers. I naturally argued against it. My mother finished civil engineering, and I strongly believe in the elegance, timelessness and excellence of engineering. This morning, as I struggled with and later killed my groupware program over a dispute of syncing with my Palm, I solidified my stance against the idea of treating programmers as engineers. Here are seven reasons why programmers are NOT engineers.

Sin 1: Documentation
Most programmers do not document their code. Some of them say that code is self-evident, self-describing and self-documenting. Tell that to the poor souls trying to extend or maintain that glob of code you brain-dumped.

Now take a look at a blueprint of an engineer. What would happen if some of the measurements disappeared or someone forgot to label the room that holds the AC.

Sin 2: Testing
Programmers do not test their programs effectively. You wonder why your state-of-the-art PC keeps on crashing, as soon as you plugin that expensive computer card? Or just randomly? Testing frameworks, and concepts exist, but with the exception of a few individuals, no one does a decent job of testing. Whining about different configurations and different users does not help.

When an engineer designs a skyscraper, he/she needs with the whims of people, animals and nature. That is why after an earthquake, skyscrapers and bridges still stand in San Francisco.

Sin 3: Research
Programmers rarely research anything. They simply build a new toy program, and expect everyone to love it. They expect that they can experiment away, and deploy an untested and unthoughtout innovation.
Then surprise and dismay occurs when their innovation is unwanted and even hated.

In engineering, most innovations need a huge amount of research. Engineers need to design, test, and re-test ideas until they know they work. An engineering innovation never builds upon a brand new untested technology.

Sin 4: Meeting Requirements
“I’m the programmer. I know what my client really wants.” Wrong! This cocky behaviour of coding what the programmer wants, and not what is required happens way too often. User requirements often go unresearched or ignored. The users become upset at the developers. Company gets into trouble. And the programmers are forced to fix their mistakes.

Engineering anything revolves around meeting some need or requirement. These requirements and the challenge of meeting is at the heart of engineering. If the client wants a skyscraper in the form of a glass inverted cone, the engineer has to build it. But the engineer must find out, understand and then build according to the clients and the universe’s requirements.

Sin 5: People Skills
When things go horribly wrong, who gets the blame? If a building falls (without an obvious catastrophic uncontrollable reason), the engineer gets the blame. If a user’s data vanishes in a simple operation, the user gets blamed. Programmers always blame their clients of incompetence, even when a problem is caused by bad programming.

This behaviour goes beyond just blaming. Programmers ignore the advice and problems of their users, and keep their jobs. An engineer who does likewise, gets fired.

Sin 6: Reliability
Programmers suffer from terminal featuritis-o-philia. They program a new feature and continue on innovating, all when their program lacks stability of any form. User start believing that programs and computers have a mind of their own, with data disappearing, malware crippling systems and hardware crashing inexplicably.

Engineers strive for reliability. Ever building is designed to last the harassment of humans, nature and even “acts of God”. Every vehicle should not kill its occupant, unless a total, catastrophic disaster occurs. Wondering why to this day, the crash-proof operating system and program is still a dream? Reliability takes second step to “innovation” and “coolness” in the minds of developers.

Sin 7: Overall Cuteness
If there is a single profession I can think of when you can get away with unprofessional “coolness”, it is software development. Programmers love to use obscure shorthands, bizarre implementations and wacky ideas, even competing annually for the “cutest” piece of code.

Cuteness is a sign of un-professionalism, and often immaturity in the real world. A cute engineer is a starving engineer. A cute programmer is a thriving one. See why programmer’s can not become software “engineers”?

Finale
My rant ends now, and I know many will complain that I overexaggerated. True, there are some programmers that do not sin in the above ways. They are the exception. Most programmers pass themselves off as good, and still sin terribly along the way. An engineer who sins as such is a bad engineer, and rightly so. I claim that if programmers ever want to earn the distinction of software engineers, they need to raise their standards considerably higher.

Harnessing Chaos: A Framework for Team Management

Posted on by

Programming is a misunderstood art. Unfortunately many commercial ventures treat programming like a science and managers treat programmers as engineers. Engineers build things based on repeatable technologies and designs. Programmers craft code, a process more akin to the unpredictable and unrepeatable production of art like writing. Companies get in trouble when they try to apply engineering best practises such as enforcing strict requirements, and tight predictable deadlines. A far better approach works by treating programming as an art, and applying artistic best practises.

The Problem of Creativity
One problem with creativity, is that is hard to predict and control. Creativity comes and goes, at a whim. Since artists work in a creative manner, they need a great degree of freedom in their work. Unfortunately the real world treats art in the same way as it does engineering. The real world expects predictable work schedules and techniques.

This becomes problematic when programmers work on a project as a team. The team needs to balance creativity with reliability. So artists and programmers need to build predictability into their projects. One way to create repeatable and scheduleable for creative work is to use a framework.

Team Frameworks
I am an extremely individualistic person. Yet, I will admit many projects simply take too long for a single person to do. Teams naturally alleviate this problem, by throwing more people at a task. But like Fred Brooks mentions in his The Mythical Man-Month, throwing more people at a team does not guarantee faster completion.

One of the reasons, I dislike teams is the problem of expectations. Before starting on a team project, I find it best to lay out “ground rules”. The rules include:

  1. Quality Expectations
  2. Communication
  3. Scheduling
  4. Individual Talents
  5. Work Synchronization
  6. Task and Job Division

It is important to work out these rules early on in a long term project. Without getting into specifics of each pint, I think everyone on the team needs to know what is expected of them. This saves the trouble of anguished team members when things go wrong, which in any project always does.

It is essential that these rules (not guidelines) be in place early on. Also every member of the team must follow these rules religiously. Sometimes the rules need changing, but if you did a good job on setting them up, the rules should not drastic changes.

Buffer Schedules
Programmers are notorious at underestimating the time required for work. The problem of “engineering” comes into play, and the result is delays in work. Instead when working on any creative project, you need to schedule in “thinking”, “wasted” and “oh crap, this is all going to heck” time.

The best of doing this is to schedule in a buffer. I usually work on a 1.5X buffer, (which probably is a very short buffer and 2X, even 3X are preferable). A 1.5X buffer basically adds an extra half “of time I think this will take me”. So if I think something takes 2 days to do, I try to schedule 3 days. This gives me room for error and I can finish ahead of time rather than “after-time”. Many successful programming groups also use buffers in scheduling.