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.
In order to focus on just the algorithm during development, I coded it in StackBlitz. Below is my running example, developed in TypeScript. All up it took me about 5 hours (including understanding the requirements, a couple of missteps, and cleaning up the code).
If the data names seem strange that’s because it’s for biological data in a web application we’re developing.
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.
index.ts contains the sorting code
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)
- Electrical / Electronics
- Packing cells (small, medium and large)
- Place socks inside shoes.
- Face wipes/wet wipes
- Currency for each country visited.
- Small denomination currency for tips, beverages.
- Spare batteries
- Battery charger
- SD card reader
- Cleaning Cloths
Person who believes fortune cookie also sees future in their tea.
16 years of building forms-over-data web applications can leave you wanting for more when you’re still doing it 8-hours a day on a brand new monolith application that requires 15 files to be changed just to get data from a new table to display in the front-end.
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.
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:
- Developers who did not think about the implications of what they were asked to do;
- Vulnerabilities in the code they wrote.
No, they don’t.
Twice today I’ve heard the exact phrase or a comment equalling 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:
- Every single one of us is guilty of being a “stupid user”.
- 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.
gerund or present participle: chafing
(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 weekend.
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:
- 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.
- 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.
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.
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)?