Month: March 2018

Sorting algorithms can be difficult, but I gave it a crack and here’s what I produced

Posted on | by Jason Snelders

I find sorting algorithms difficult. I also find recursion algorithms difficult (that’s another story). My brain isn’t really wired very well for algorithmic thinking, which is probably an odd thing for a software developer to say.

My day job today required me to write a reasonably complex sorting algorithm in JavaScript on a data set that required grouping and multiple layers of sub-sorting. Conceptually it’s actually relatively easy – as this answer on StackOverflow suggests – but life is never that simple.

In order to focus on just the algorithm during development, I coded it in StackBlitz, a relatively new online IDE/sandpit for JavaScript based projects.
Below is my running example, developed with TypeScript. All up it took me about 6 hours (including understanding the requirements, a couple of missteps, and cleaning up the code, then refactoring into modules/files).

If the data names seem strange that’s because it’s for biological data. I’ve left out all the unnecessary fields and focused purely on the fields that need sorting (except for the ID and Rnd fields).

I’ve added the sorting requirements into the code, but here’s what we needed (exactly as received):

  • Group by DSA Category (Specific first, Potential next)
  • Then Group by Locus, get the highest MFI for each locus, and sort locus by highest MFI to lowest
  • Then sort antibody (the same antibody should be grouped together) by MFI highest to lowest.
    [JS: Another way of looking at it: Group by locus, and find the highest MFI for each locus. Then within each locus group by antibody. Then sort antibody within each locus by MFI, highest to lowest. Then step back up to locus and based on the highest MFI found within the locus, sort each locus “group” by that MFI, from highest to lowest.]
  • Then sample date

 

Running Example

NOTE: You can pop the editor open in a new window by selecting “Edit On StackBlitz” in the bottom-left of the inserted window.
Select the folded-page icon at the top of the left column (below the StackBlizt blue/white icon) to see the list of files.
The code is split over multiple .ts (TypeScript) files, and index.ts is the starting point.

If you’re using Internet Explorer or there’s just a black window below, here’s the link to the code (and I suggest using a “modern” browser – Chrome and Edge both work): https://stackblitz.com/edit/js-complex-sort.

Travel Tips & Checklists

Posted on | by Jason Snelders

Checklists and tips from many years of experience travelling within the country and overseas.

 

Travel and Packing Tips

  • Buy different size packing cells and pack your clothes, electronics and loose items into these. You bag stays organised and clothes tend to crinkle less.
  • Get to the airport or train station early. There’s nothing worse than starting a trip (or leg of a trip) stressed and rushing to the departure point.
  • Split your money. Keep backup money/credit card in your luggage (or hotel room safe) when you’re at your destination.
  • Scan or photocopy your passport and travel documents. I’ve never needed to use a scan but a back-up is a relief.
  • When travelling overseas
    • Scan or photocopy your password, travel document and itinerary and give it to your parents/relatives/best friend in case of emergency.
    • Check you’re nations overseas advisory service (e.g. smarttraveller in Australia).
    • Check the visa requirements for your destination country well before time.
  • Place spare socks inside your shoes. It makes good use of dead space and saves the toes of shoes from caving in/crinkling.
  • Take a power board on all trips. In most hotels power points are hard to access (e.g. behind the bed or couch) and there are never enough outlets to charge multiple devices (especially when travelling with a partner and you have phones, tablets and cameras requiring a recharge).
  • Buy portable batteries to recharge phones and tablets.
    • I have a Cygnett ChargeUp Ultra 20000mAh power bank which gives up to 10 phone recharge, ideally for my wife and I for long waits in the airport or long periods away from power.
    • I also a lighter weight Cygnett ChargeUp Rapid 5000mAh for when I need spare power but don’t want to lug a brick around (I always have one of these in a bad or nearby, even at work).

 

Before the Flight Check-In

  • Remove multi-tool from my wallet (put it in check-in).
  • Remove any sharp items from carry-on bags (put it in check-in).
  • Make sure carry-on liquids meet regulation.

 

Before Boarding Flights

  • Any items you want easy access to while seated, place them in a small packing cell or sling bag and keep separate from your normal carry-on. That way while boarding you can through your loose items on your seat, chuck your carry on in the overhead bin, and not hold up everyone else. It also keeps all your loose items together and easy to find.
  • Buy a bottle of water. Extra water can be a lifesaver, especially if you need it and air staff cannot serve you immediately.

 

Packing Checklist (mixed national and international)

 

Sites

Find top people to follow

Posted on | by Jason Snelders

A tip for junior and student software developers:

Find the top people and organisations – the thinkers, leaders and “doers” – in areas of interest to you, and follow them.

Good people and organisations write regular blogs.

As bad as Twitter can be it’s a great place to find leaders in technology and software development. Twitter can also give you a closer to real-time flow of information and some good conversation to get you thinking.

Also, check if your favourite people are authors on Pluralsight.

“Users” are real people

Posted on | by Jason Snelders

And we have an ethical responsibility as software developers – and, for some, “hackers” – to consider the implications of what we create and do.

Users are people. Real people, like us, living real lives.

What we do has a real effect on people’s life. Now, and in the future.

Example: https://www.troyhunt.com/heres-what-ashley-madison-members-have/ and Troy has also noted some people have committed suicide over this breach.

 

If you were a software developer “just writing code” and created something that, how you feel if I:

  • Collected all your data, collated it and create a “profile” of you to sell to others for the profit of others?
  • Could learn so much about you it could create a “virtual you” that over an actor that could make you say and do things you never did?
  • Allowed your identity to be stolen?
  • Allowed your most personal information to be stolen?

How would you feel?

Well, all these scenarios have happened over the last couple of years, and all thanks to just 2 reasons:

  1. Developers who did not think about the implications of what they were asked to do;
  2. Vulnerabilities in the code they wrote.

Users do stupid things

Posted on | by Jason Snelders

No, they don’t.

Twice today I heard this exact phrase or a comment equaling it:

users do stupid things.

One instance was in relation to registering scores for the CrossFit Open. The second time relating to storing passwords on Post-It Notes.

Sure, it’s easy to say the person was stupid. They should have read the instructions. They should have understood the rules. They should know better.

But let’s understand 2 things:

  1. Every single one of us is guilty of being a “stupid user”.
  2. People simply take the easiest path to completing a task. It’s not their fault the path is wrong or insecure according to someone else’s standards – they just want to complete their task and get on with the day.

So no, I don’t believe there is such a thing as a stupid user.

In every instance, it’s a case of a poorly constructed interface or system, bad policy, or lack of good tooling that allows poor users to select the wrong easy path to completion.

Chafing

Posted on | by Jason Snelders

Chafing

/tʃeɪf/

verb
gerund or present participle: chafing

  1. (with reference to a part of the body) make or become sore by rubbing against something.“the collar chafed his neck” synonyms: abrade, graze, grate, rub against, rub painfully, gall, skin, scrape, scratch, rasp;

 

I don’t mind mentioning it: I get chafing around the inside top of my legs.
It’s summer. It’s hot. I’m have a naturally good internal heater that never turns off. So I sweat.

Plus I cycle to work. And on weekends.
Finally, I spent about 12-14 hours a day, 5 days a week, sitting in front of a computer.

Lots of heat. Add some friction. In high volume. You’re bound to get some chafing around the nether regions.

 

So I recommend 2 things to ease chafing:

  1. Talcum powder (also known as baby powder): I started using it this year after I got recurring chafing for the first time. It helps to absorb moisture and add an extra layer of protection against direct skin/clothing rubbing.
  2. Lucas’ Paw Paw Ointment: I do believe this is an Australian company, so I’m not sure what the international availability or equivalent is. But I’ve started using it to relieve chafing I wasn’t able to fend off and it really does provide relief. My wife has also been using it for some time on bug bits (bugs absolutely love her) and chafing as a result of CrossFit.

Write comments in your code

Posted on | by Jason Snelders

I recommend adding these types of comments when writing code:

  • Classes: A brief description of the class purpose.
  • Functions/methods: A brief description of what the method does. It’s also good where possible to provide descriptions of the expected parameters and return value if applicable.
  • Properties: A brief description of what the property is for.
  • Most code has some logical grouping as it flows. Add a one or 2 line comment before each section describing what’s happening.
  • If you write a complex piece of code/algorithm/fluent method chaining, add a description of what’s happening. Sometimes it’s difficult to determine what’s happening from the code alone.

Why is commenting code good?

  • Put yourself in the does of someone who has to change the code later. Comments help other developers (and often yourself) understand what is happening, and what is supposed to happen.
  • Comments are helpful in debugging errors, where the logic of the code may not match the expectations set out in the comment.
  • Comments help other developers determine if a method or class is something they can use in their own code.

Do software courses with “advanced” in the title mean we’re making the subject too complicated?

Posted on | by Jason Snelders

Looking over some developer blogs of Pluralsight authors I was seeing their course titles and I realised something:

When a course has “advanced” in the title does that usually mean the subject matter is more complicated than it should be?

For example, “Advanced Dependency Injection”. Surely Dependency Injection is something we want to keep simple (though to be fair I argue everything should be kept as simple as possible)?
Can’t we just wire it up then get on with the real job at hand? What make’s it so complex there must be an “advanced” component?

It leads me to wonder why we even need a sliding scale of “easy” to “advanced” topics in software development?
What causes such complexity in a subject?
Is the topic truly large and complex?
Or are we, the developers, so lazy in our approach to implementation – or teaching – that we over complicate it (almost certainly unintentionally)?

If you tell someone they’re coding wrong, then tell them ‘why’.

Posted on | by Jason Snelders

I’m writing unit tests in xUnit and have the following example asserts:

Assert.Equal(5, results.Count);
Assert.Equal(0, results.Where(r => r.MatchResult == ComparisonMatchResult.InvalidDonorAllele).ToList().Count);
Assert.Equal(1, results.Where(r => r.MatchResult == ComparisonMatchResult.Potential).ToList().Count);
Assert.Equal(4, results.Where(r => r.MatchResult == ComparisonMatchResult.Specific).ToList().Count);

However, xUnit gives me warning squiggles and messages like this:

xUnit - Do not use Assert.Equal() to check for collection size.

When I Google for the warning to find out more I come to https://xunit.github.io/xunit.analyzers/rules/xUnit2013.html.

The problem is that page – nor any other page I can find so far – tells me why I should not use check collection sizes when there are zero (0) or one (1) expected elements. Why are there specialised assertions for these 2 specific cases? Why am I penalised for writing code in what I feel is a consistent and, I believe, easier to read way?

The moral of the story for developers: if you’re going to tell someone they’re doing it wrong, please also tell them why they are wrong and why the alternative is better.