stephengream

[stephengream]

Prusa i3 Mk3S Build Roundup

My order got in on Monday, only 10 days after ordering it. Was pretty impressed because I got a message about 2 or three hours after ordering that it had been dispatched from the factory, so massive ups for that one Prusa, you magnificent Czech. It took me around 12-14 hours over the course of a few weeknights, you could probably build it a bit quicker if you were better with your hands than I am.

Pulling it out of the box, everything was sorted nicely into many boxes, with printed parts in one, screws and electronics in another, etc, all numbered with the step they would be required for.

Starting the build Monday night, I managed to get the Y-Axis frame put together in about an hour and a half, then quickly knocked together the X-Axis frame taking around another half an hour before heading to bed.

Tuesday night was the Z-Axis and extruder housing, which I didn’t finish all in one go. Was up until about 1am and only managed to get about halfway through it, it was a pretty long slog.

Last night I finished the extruder axis, the LCD screen and PSU power unit, which took around 3-4 hours, then started hooking up the electronics before heading to bed at one, leaving it half finished. 

Today after work, I finished wiring everything up and started calibration. Here I ran into issues where my PINDA sensor didn’t seem to be as sensitive as it should have been, so I spent about an hour running the calibration wizard, feeling the extruder nozzle dig into the paper I was holding, aborting, ratcheting down the PINDA, rerunning the wizard, etc. After that, it was clear sailing. My first print was a frog from the included SD card, which I’ve given to my wife to put on her desk at work.

Some of the issues I ran into during the build, all of which are down to my lack of experience:

Took a few goes to get the Y-Axis flat. Learned very quickly to RTFM very carefully, as it goes into general good build tips to make sure everything is precise

Some of the printed parts were very difficult to slot nuts into. I got the knack a little way on, but particularly smaller parts the fit on them was very tight

I don’t really have a way to prop the frame up if I need to get underneath it, little concerned I might break something if I need to monkey with the Y-Axis belt or fiddle with cables underneath the printer

Gotta look into the autoload stuff, I ended up having to turn it off to get some filament loaded up. 

I managed to scuff up my printer bed a little and leave a deep gouge in one of the steel sheets. Be very careful and attentive while you’re calibrating this thing, because it’ll sneak up on you like that. No permanent damage and I still have a sheet that’s good on one side, but frustrating to say the least.

All in all, had a great time building this beast, though for a complete beginner that doesn’t know their tools I wouldn’t recommend it. I also wouldn’t recommend buying a prebuilt kit unless you’ve already built one before and know how it all works. I would have been dead lost with some of the calibration problems I had if I hadn’t have built this thing.

Going to try and set up Octopi on it next, not for any real reason since I can quite easily get a USB cable into my desktop from where it is, but it will be a fun little project. 

[stephengream]

Gonna try to get back to this

Welp, I’m going to need to get back into a habit because I got a new job and they expect me to do something blog or community related.

I’ve been working at this spot for the last week, and have been on the bench while we rustle up some new clients to work with, so I’ve been taking the chance to earn a few certifications that I really didn’t get time to do in my last role.

The funny thing I noticed is that despite having had a hand in building a large system using AWS in my previous role, I still missed a large number of questions in the practice exams I got. It got me thinking; How can I, as an engineer, best conduct my own self learning and use that to spend my time as efficiently as possible?

I started by having a look at what I got wrong on the practice exams and narrowing it down to broader topics I could look up. While I was pretty competent in knowing what various products were used for, what I didn’t know were the little intricacies and limits that Amazon imposes. Things like Dynamo read and write capacity units, obscure terminology I didn’t really need to have anything other than surface level knowledge of and processes that happened under the hood. I prioritised learning those small details over the last few days, and now I just have to drill myself tomorrow and probably Monday to get myself ready to take that test.

Was an interesting little eye opener into the way I like to learn. It kind of reminded me why I hated uni, whenever I had a lecture on I ramped it up to 2x speed so I could get through it and pause on anything I wasn’t so sure of. Will have to see if I can somehow turn this into an even faster feedback loop in the future.

[stephengream]

Getting Wifi Going With Hypriot and Raspberry Pi 3

This week I bought a few Raspberry Pis to set up a small Kubernetes cluster to deploy a few of my apps onto a lower power machine rather than my desktop to save some power.

I chose Hypriot because it’s focused on building Docker capable machines out of the box. At this point, I had a bit of an issue, since I don’t have enough ports on my switch to plug all these in. So I decided to go down the wifi route until I have a chance to do my research on a decent switch (my fiancee is a long suffering woman, I have so much random tech hanging around the house and am constantly talking about getting more).

Looking around the internet there’s a few people talking about how it won’t work out of the box, so I thought I’d put this up to show how to set it up manually without needing to fight with the flash utility.

I’m going to skip over the flashing to card part, since that’s already covered pretty thoroughly on the github page.

The next step is to get into your Pi, via SSH or physically, and to generate a wpa_supplicant file. Run 

wpa_passphrase <YOUR WIFI NETWORK> | sudo tee /etc/wpa_suplicant/wpa_supplicant.conf

This should create a file that looks a little like this 

Type in your passphrase and hit enter. This will create a configuration file for you to use in connecting your network.

Next we want to set up the wireless interface. For me this always identified itself as wlan0, so that’s what I’ll show here. Run

sudo nano /etc/network/interfaces.d/wlan0

And paste in 

auto wlan0 allow-hotplug wlan0 iface wlan0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

When you reboot, your Pi should automatically connect to your wifi network if you have DHCP enabled on your router. If not, I assume you probably know how to spin up a static IP.

Have fun and happy pi-ing!

[stephengream]

Docker Gotchas

Quick one this evening before I go to bed.

Currently building a complete system in docker. This includes my services, databases and rabbit server. I eventually decided to make the move over to Docker Compose and have spent the weekend containerising all my services so I can very easily bring up and tear down services, as well as write more automated integration tests for them.

Had a few teething issues relating to it, though, so just a quick list:

Sometimes, at least in docker for windows, things just gum up and you need to restart the Docker service. I never had this problem on Linux, ever, but if something is just refusing to boot or behave correctly just restart the service. Another one I’ve been having from time to time is that the port forwarding just doesn’t work. Reboot the docker service and it should fix it

Postgres containers with external volumes won’t update the passwords if you tear them down. I spent an hour and a half trying to figure out why I couldn’t get a connection into one because of this

Not so much docker, but Spring Cloud’s Eureka service clients don’t like underscores in their names. Use hyphens or dots instead

Remember to port forward if you want to access services from the host

Another Spring Cloud note, the tutorials for it don’t mention how to get the service to hand out the correct address to call it. Use the eureka.instance.hostname and eureka.instance.port configuration keys to set that. I passed these in as environment variables in my docker compose file, though I imagine there’s probably a better way to do it that I haven’t found yet

I think that’s about it. If you find this I hope you find it useful.

[stephengream]

Advice to CompSci students and recent graduates

I thought I’d give some advice to people from a seasoned engineer. I’ve been in computing since I was 19, so nearly 10 years now, and I did this when I actually used tumblr regularly and got a fair few reblargs about 5 years ago, so I thought I’d repeat it now that I’m a little older an more jaded and see how we go. So let’s get started!

UNIVERSITY DEGREES DON’T MATTER IN THE LONG TERM

This is probably the hardest thing to swallow. You work your ass off for 3 or 4 years at university for what? A bit of paper? Truth be told, after a couple of years working nobody will care, and it will count for naught.

NOBODY GIVES A SHIT ABOUT YOUR MARKS... IF YOU’VE BEEN WORKING

Want to know my average mark? Somewhere in the 65-70% region. I pulled a Credit or distinction for most courses. What did I learn? Some fun stuff, but not much of it was useful outside algorithms, software construction and design. The other courses I did were cool, but I learned way more by diving into relevant open source projects.

To be completely honest, the best engineer I know is a university drop out, so don’t sweat it if you fail a course or two. With some work there’s still going to be pathways for you.

As a thought experiment, put yourself in the shoes of a potential employer. They have two candidates, someone like me, not getting great marks, but has been working nearly fulltime through university and has a great reference from his old boss, and someone with no work experience but a straight 90% average mark. Who is a less risky choice? 

The person with the job has worked with computers in a practical setting, outside the lab, and had to deal with the consequences of his or her decisions in real life. The person that’s concentrated on uni? Sure, they be smart, but have they ever had to deal with a stakeholder? Have they had to create actual working pipelines for their work? Have they ever had to support and maintain any of their code after an assignment? 

Who will take less time to get up to speed in this situation? My advice is that if you enjoy study, great, whatever, but remember that universities will never drop you in a situation where everything is burning down and expect you to fix it. The earlier you learn to cope with that scenario, the better, and as it becomes a routine thing you will start to form practical links between your study and useful information, thereby beefing up your marks with minimal extra study.

MANAGE AND TRACK YOUR TIME

This isn’t what your parents tell you, "you spend too much time playing computer games and on that god awful tumblr site” is an astute observation, but not something you can really action in isolation. What is useful, however, is knowing how you spend your time and how you can optimise it. This is perhaps the most difficult thing to do, because it’s tedious and boring, but even just setting your timetables and work times in your calendar as a recurring event can help, and from there you can start to have a better idea of how much time you actually have to spare every day. Get into the habit of this, and I promise you, you will never run late or work overtime ever again.

MAKE NOTES ON WHAT YOU’RE DOING

Lectures, eh, I never found notes that useful since they were all recorded. Personal taste though, I know a lot of people that lived in their notebooks.

That being said, I do keep a very tight grip on my design and implementation decisions. I like using OneNote for this, because I can quickly scribble down ideas and to-do lists, and paste in code snippets for later. Another program that could work is Scrivener, and one of my classmates even kept an Excel spreadsheet with a workbook for each thing he was working on (I suppose you could use something like KEdit or Atom, but I like to lay things out in a very specific way so I don’t have to scan through anything. Find what works for you and keep it that way). When it comes time to stand up in front of my team and tell them about the project, I can always answer any question thrown at me. I don’t have to sit there thinking about it and trying to remember exactly why I chose library A over library B or why I thought this class was garbage and restructured it.

CONSTRUCTIVE CRITICISM IS A CHANCE FOR YOU TO IMPROVE AS AN ENGINEER, IF YOU GET HUFFY YOU’RE MISSING OUT ON A GREAT OPPORTUNITY

Leave your ego at the door and be a team player. You’re never going to be alone on a project, and you’ll do well to listen to your teammates and converse with them in calm terms. 

If you get upset every time someone makes a suggestion on how to improve your Already Perfect Code™, not only are you going to look like a pompous dick but you’re going to completely reject this lesson someone is offering you for free. Everybody is there to get their job done, and if you get in the way and refuse to compromise and discuss your implementations you can’t expect to keep your job for long.

The flip side to this is that not all advice is good. In time you will learn to recognise this, because shitty advice will make your job harder, but when you’re just starting out it’s best to assume people probably know something you don’t.

CODING STYLE AND NAMING STANDARDS MATTER

You want to know what the stupidest argument on the internet is? Tabs v spaces. It gets nasty, and I saw classmates in uni get into yelling matches. My opinion is I’m a spaces guy, but I do what the rest of the team does. Why? Because consistency.

Have you ever opened up an old project you worked on at uni with a few different people and thought “oh dear god, what were we thinking”? I can assure you that part of this mess will be down to the different styles you all employed in your code. When doing this in a professional setting, it needs to be consistent to ease readability and ensure the team doesn’t misinterpret code. The lucky thing is, all the best IDEs have plugins that will do all this for you and throw warnings when something isn’t right.

PEOPLE SKILLS ARE PARAMOUNT

This doesn’t apply to everyone, but I know that a lot of us are basement dwelling nerds, but being awkward is something you need to get past. Working in software is just as much about your interactions with people as it is how good you are at making computers do what you want. How can you expect to get a good list of requirements from a client if you’re too shy to ask them tough questions? How do you function in a team if you can’t communicate with the people assigned to help you on a problem? 

This is definitely something that can be learned if you put some work in. The way I did was just to hit it head on on the job and start out just trying to reword what the client was telling me they wanted. It’s not ideal, but it took a lot of awkwardness out of the exchanges I had. From there, I just started talking to people in bars, not hitting on anyone, just chatting while we were in line for a drink or something. Didn’t have to be anything specific, I just said the first thing that came to mind, and boy did I spill the spaghetti more than a few times. But you know what? I learned from it, and become much better at at least pretending I wasn’t a giant, awkward weirdo, which leads me to my next point...

ADMIT YOUR MISTAKES EARLY AND LEARN FROM THEM 

You will fuck up. You are not perfect. Do not double down, especially when you’re brand new to the workforce and everyone will grant you three times the patience they’d grant to someone like me. Every time you screw something up, you will learn way more than if you did it right first time, so don’t sweat it and learn how to admit to your own failures and work on fixing them rather than learning how to cover them up.

DON’T BE AFRAID TO MOVE ON

‘nuff said. Always keep abreast of the job market and have your resume ready to go with a number of cover letters for different types of employers. Consider this a risk management and profit maximisation strategy if nothing else, and always know how much you’re worth to the company you work for (and be honest to yourself about it). In saying this, though, I tend to aim for a minimum 2 years with a company outside of contracts. It takes a while to onboard someone and bring them up to speed, especially in software, so be mindful of how it would look if you moved around too much.

This point is something I can definitely reinforce with my own personal experiences. I’ve been through 2 redundancies up until now, and both were for similar reasons, in that I was cheap to move off the work roster. My first I was on casual time, so wasn’t legally entitled to any redundancy payout, and the second because I’d only been with the company for a year and was only entitled to a small payout. 

The other thing to note here is that if you work for a small company, chances are someone high up will do the firing personally. For me it was the CEO in both situations, so don’t burn your bridges here and be an ass. A personal endorsement from a C level executive will net you serious credit and at least an extra $5-10k at your next position, so be professional and make sure that’s the image of you they keep in mind when someone comes ringing for a reference.

LEARN AUTOMATED TESTING

If you’ve never worked in a real setting, this probably sounds stupid. 

“Why would I write tests when I can just run the application and look at the output myself?”

Oh my sweet, summer child.

This one will come in handy for when you’re sick of spending 5 minutes loading up an application, clicking through and getting your inputs right, then waiting for it to finish. There are many different schools on how to do this, but truth be told even though nearly every company does it, most people on a team will do it slightly differently. 

I’m of the school that will figure out the outputs for each component, write the skeleton for each one, then write the tests after having a basic implementation in place. This works for me, because I will often change the architecture and interfaces of an application as I go along and learn more about the problem domain.

On the other hand, my teammate will write the tests before she does anything else and generate stubs for everything she has to do. This is also a perfectly valid way of doing things and one I’ve seen used a lot, but it does require a more in depth plan and better understanding of what you’re putting into place before your fingers even start to tap out that code.

The third “correct” way of doing it is developing the tests as you go along, which is also perfectly valid, though I find with the way I work it adds a lot of overhead in my development time.

The process here is a personal one, and I’ve had a lot of heated debates in the past with zealots who insist on a particular way. Don’t be that guy, because as far as I’m concerned you need to find out which way works for you and stick to it while letting other people be productive in the way they do things.

SHITTY LANGUAGES THAT EVERYONE USES OFTEN HAVE AWESOME TOOLSETS AND ECOSYSTEMS

Yes, Java is shit, I know, but have you ever used Gradle?

How about JavaScript? Node is popular for a very good reason, you know.

Before completely dismissing a technology, be sure to check out what people are doing on the edges. I was a .NET programmer for many years and was locked into the absolutely amazing C# language, but the horrendous MSBuild build system. I started looking over the Java side of the fence and found a wonderful ecosystem full of amazing tools and even more amazing and dedicated developers maintaining them. 

The rule of thumb is, if the language is shitty, people will build some cool tools around it to overcome its limitations. If the language is good, it can be a victim of its own success in a lot of ways. Don’t just look at a language, much sure you look at the tools that come with it, too

READ AS MUCH AS POSSIBLE

Yes, this is where I crack out Stephen’s must read list: Software edition.

Code Complete - Seriously THE book for amazing software construction. I’ve read my copy many times and keep it handy to refer back to it a lot

Introduction to Algorithms - The only textbook from uni I keep coming back to. An absolute treasure trove of great info, and provides insight into why your application is running really slowly or blowing out its memory heap

 Introduction to the Personal Software Process - Want to be a better engineer? Read this, and figure out the best bits that apply to you. It’s bureaucratic, but it’s where I got my obsessive note taking and time tracking from and I stand by it as one of the best process oriented books I’ve ever read

Refactoring to Patterns - Your code is garbage, but you can’t quantify exactly what’s wrong with it? This is the book for you, and as a bonus it will help you fix it in a sensible way. Great as a reference, and I keep the quick reference list from the inside cover in my laptop bag.

Patterns of Enterprise Architecture and Enterprise Integration Patterns - These are fucking cumbersome tomes and very difficult to slog through, but will serve you well with some of the stupid, overengineered crap people have done in larger systems. 

Continuous Integration - This is what’s done in the real world. Learn what it is and how to do it.

Continuous Delivery - Some places do this, but most really need to start. This book is a little enthusiastic about it, but the points it makes in regards to delivery methodology are spot on

The Lean Startup - You want to start your own million dollar company? Of course you do. Read the shit out of this one and learn what it means to be a customer driven, adaptive company. It will also serve you well working in agile teams, as you can help institute better processes and understand why things are done in certain ways.

Risk and the Smart Investor - “Yeah man, but I’m a free spirit hacktivist and I’m going against the man I don’t need money row row fight the powah”. Yeah, ok, I was young and unemployed at one point too. When you’re ready to be an adult and learn how to make your money work for you, spend the $20 on this book instead of Twitter or Yahoo shares. It walks you through various ways of hedging your risk and diversifying investments while also telling you the stories of two men who have lived very different lives and how they’ve spent and invested their money. If you want to make sure you don’t get suckered into a get rich quick scam and have a little nest egg put away for your twilight years, this is vital reading.

And that’s about all I can think of right now. I will try to blog more, I have some ideas for some home projects that I want to pursue over the next couple of weeks so I can get some things straight before I need to do them at work, so will probably write about them. Lately my routine has been wake up at 6:30, at work by 7:30, come home 5:30-6, go to the gym for an hour, come home, practice guitar for an hour or two, then go to bed. Absolutely thrilling lifestyle, but it should start to slow down in a little soon as I settle into this new job. 

[stephengream]

New Job!

Start on Monday as a senior engineer in the Melbourne CBD. Lots more responsibility, but it should be a great gig to push my career forward.

Will probably have more to blog about, since there’s going to be a lot of new stuff, especially around process automation and improvement, as well as a lot of tooling work. Looking forward to doing a lot more cloudy projects as well, since as of yet I’ve not had a lot of exposure to them.

I also joined a band a few weeks ago. The guys have some great musical ideas and a lot of creative energy, so I’m glad to be a part of it. Been listening to a lot of Swallow the Sun and Alcest hoping to bring parts of their sounds into my guitar playing as well. Hopefully it all pans out.

[stephengream]

Of Testing and Canaries

Continuing on my theme of testing, last week I was caught a little short after deploying a new version of one of the applications I maintain at work to production. 

Long of the short, we back on to one of the other teams’ products, and so need to collaborate with them in order to make functionality additions if and when we need them. 

Story time today involves an update that I should have been aware of, but wasn’t paying enough attention because of my other work commitments. There was a change in the release of the other team’s product, all well and good it was tested to the n-th degree within their stack.

The problem arose after I ran all my testing to completion on the dev cluster (where I have my own segments of data and report objects, which are all pretty basic but work are all pretty good as a manual, last minute smoke test for 90% of cases we could encounter), and then deployed to production. I decided to run segments and reports that others had created, since they were obviously going for something other than what I was, and it would help test something a little more real.

I queued up the report, waited the 5 minutes for it to run and.... Bam, failure to deserialise an enum value coming down the wire. I did the natural software dev thing of panicking, “oh shit, I just pushed broken code to production, RIP my job”. Turns out it wasn’t my code that broke it.

After investigation of the problem, it became pretty obvious there had been changes in the service code, and one of the enum types had a new value. Half an hour later, I had the patch out and deployed, and everything was running happily again.

Now, I could push blame around, but I believe that this one is on me. Primarily because

This is my code, I've essentially grabbed this project and taken it where it needs to go, including working with the other team

I should have been paying more attention

There weren’t any automated tests that might pick up on this

So my immediate reaction to this is to libratise the necessary DTO objects from the other team. While this help somewhat, it still doesn’t help when we don’t have any impending builds.

My second thought is that we need to automate it. This is NOT something myself or the other team should have to worry about in the course of our BAU work. If I need to take 20 minutes out of my day to test that this tool works with every release the other team does, then I consider that a failure in my process that needs to be addressed. 

I think my end goal here is to just know when something important has changed, even if I’m not going to act on it. Being aware of a problem before a client is puts the dev’s best foot forward, as you can proactively assign resources and manage client expectations as you work to remedy it.

In reality, I suspect this may be a three prong process. I’m going to need our report generator service to be a little more robust as well, and not kill a run if we can’t deserialise an unknown value (workmate suggested using an “unknown” enum type and filtering everything that we don’t know about into that). This is probably a good stopgap while I get the testing infrastructure in place to test all this stuff against the dev and production clusters, and not just the subset of data we have in our DB container image. 

Apologies for another ramblomatic post. I’ll sit down and do a proper one eventually, just need to collect more of my thoughts and decide on a topic

[stephengream]

Integrating Docker into my Development Process

I apologise in advance for this stream of consciousness style of post, but I’m still putting all this together coherently in my head. 

Recently, we started exploring more efficient ways of doing system level and end to end tests at work. Specifics have been scrubbed, to protect the innocent trade secrets. 

We tried a few different approaches, the first of which was manually pulling down the code for each service, building it, then running our Selenium tests against the running services. This introduced a number of maintainability issues, as the number of moving parts increased, it became difficult to maintain our gradle build scripts, bring up the correct stack and configure it.

The next thing we tried was building a set of Docker images locally and running those with our Selenium tests. While this was a step up from what we were doing previously, the existing questions over the confidence we had in the binary remained, not to mention the configuration problems we had with the cluster based services and the services maintained by the other team that we required to run our section of the stack. 

We eventually had some meetings and started talking about implementing an end to end Docker stack, which needed considerable buy in. The talk about this started about mid Q4, but it took until the tail end of Q1 to actually have enough capacity to look at it (and after many discussions getting people on the same page). It was also influenced by two other large happenings internally

A few longer running connectivity issues with our dev cluster

Because of this, one of the QAs had a little bit of extra time while waiting for the issues to be resolved, so he resumed a hackday project for a “database in a can”, and pushed out a docker image with a good testing dataset

Not the most fortuitous circumstance, but it certainly contributed to, at the very least, my personal goals for the team dev and testing automation process.

The third iteration of this conversion was a list of steps to spin up a full Dockerized stack, including database, messaging queue and the required service from the other team (which also required some work to add a gradle task to build the docker image). All the build was done locally using the separate projects, and images committed to the local Docker registry. All up, this third stage took around 2 and a half weeks to get going, including the time taken to build a better application driver layer for our actual tests and adding some more cases in since the existing ones were a little out of date at this point.

This was the first proof of concept I needed to start spearheading the push for a dedicated Docker registry. After wooing my team lead and having a few more meetings to make sure everyone was still on the same page (including what was meant to be a 15 minute meeting that turned into an hour long discussion on the actual end goal of our little project), we raised a ticket for a virtual server and spun up a simple docker registry inside our own network. After pointing our system test scripts towards the new registry, we now had a system that used the same binaries that would be deployed in production after testing, and that only required Docker and Java to get running. 

I’ve been modifying deployment plans to automatically push out images to the registry this week, and my next step when I have some time is to create a Docker compose file to bring up the stack, since I’ve completed everything on the story now. 

The benefits here is now we’ve cut out a huge chunk of upfront time in getting the local dev environment set up (previously, it required about a day to get things set up and then annoying fiddling with SSH tunnels and such), and have also opened the door to more repeatable and easier to understand deployments of a few of our components. There are currently other efforts in our team to dockerize the stat crunching part of our stack, but that has other complications related to the 3rd party components we use there that make a full environment at least a little way over the horizon for now (we were already moving in that direction anyway, it’s just a matter of verification and ensuring that our existing codebase is compatible at this point).  

Anyway, it’s nearly 1am and I’ve gone through my whole YouTube playlist now. I’ve said this multiple times, but I’m going to try to make blog posts a little more regular now. I’m learning a ton lately and I need to step back and breath it in a little bit. Until next time.