Programming

Programming posts on Thien Le

• Apple Passwords’ Generated Strong Password Format | Ricky Mondello, Apple:

  To make these passwords easier to type on suboptimal keyboard layouts like my colleague’s game controller, where the mode switching might be difficult, these new passwords are actually dominated by lowercase characters. And to make it easier to short-term have in your head little chunks of it to bring over to the other device, the passwords are based on syllables. That’s consonant, vowel, consonant patterns. With these considerations put together, in our experience, these passwords are actually a lot easier to type on a foreign, weird keyboard, in the rare instances where that might be needed for some of our users.

  As someone who owns 2 Nintendo Switches and a Steam Deck, I appreciate the effort Apple engineers put into designing the password generation feature. It’s a small thing that affects people every day.

  ★

• “Programming is just too much fun to stop.”

  “Life is best lived, working hard, solving difficult problems, surrounded by friends.”

  — Tobias Lütke, Founder & CEO @ Shopify

  ★

• Taste For Good Software

  John Gruber via Threads:

  Hardware doesn’t lie. But it’s all too common for organizations to develop a culture where software product decisions are made by managers or executives with no taste for good software. It’s not that they’re OK with bad software. They can’t see the difference between bad and good software. And they foster a culture where no one who does see the difference feels like they can speak up.

  This is very well articulated by Mr. Gruber, and this is so common in our field it’s painful.

  ★

• Monoliths Are Not Dinosaurs, They Are Excellent Starts

  Monoliths are not dinosaurs | All Things Distributed by Dr. Werner Vogels:

  We always urge our engineers to find the best solution, and no particular architectural style is mandated. If you hire the best engineers, you should trust them to make the best decisions.

  ★

• You Ship Your Org Chart

  Elon Musk’s reach on Twitter is dropping — he just fired a top engineer over it | The Verge:

  “As the adage goes, ‘you ship your org chart,’” said one current employee. “It’s chaos here right now, so we’re shipping chaos.”

  “You ship your org chart” is the best summary of Conway’s law that I have ever seen.

  ★

• 30 Years Of Not Sucking

  BBEdit – free text editor | Google Groups: 

  Congratulations on still not suck after 30 (!) years 🎉 

  BBEdit is the only text editor I paid for with my own money, it is the first app I install on every new Mac. I miss it every day at work using the company’s Ubuntu based workstation. 

  ★

• ThoughtWorks Technology Radar Volume 26:

  A bit late, but the new volume of ThoughtWorks Technology Radar is out, and it still does not suck!

  It is also a chip painful since I have encountered 3 out of 4 HOLD Techniques (SPA by default, Production data in test environments, Miscellaneous platform teams) in my past projects 😂

  Web version containing the latest volume can always be found here.

  ★

• That shipping feeling | David Heinemeier Hansson:

  there are worse things to be addicted to than shipping quality goods.

  ★

• ThoughtWorks Technology Radar Volume 25 is now available! Go check it out, and don’t forget to read the themes too.

  ★

• Expect More Nuances

  Ship / Show / Ask — Rouan Wilsenach | Martin Fowler:

  When talking about patterns for managing source code branches, I used to think as a team, we can either be a “Continuous Integration team” (good) or a “Pull Request Team” (evil).

  After reading this great article written by Rouan Wilsenach, I realized there are more nuances in that (or in life frankly), and we don’t have to pick any side. He also went ahead and suggest this Ship/Show/Ask model for anyone to use for communication with our teammates, see where we are at, and working on ways to improve (if needed).

  My teams are “Mostly Asking” teams. I will try to nudge ourselves to “Showing more”. I hope to document my experience doing that here as well.

  ★

• Beth (@bethcodes) via Twitter:

  If my code doesn’t work for the changes someone needs to make, I am delighted when they refactor the shit out of it.

  It means I wrote code that a random person some time in the future felt safe and confident modifying. That is always my goal.

  Some managers wrote me when I am leaving the company saying: “You left behind big shoes to fill for anyone to take over your tasks”. I hope not.

  ★

• Why is this interesting? - The Technical Debt Edition:

  Very interesting article about technical debt, with a classic lesson from Evernote.

  ★

• Change Your Organization Or Change Your Organization

  I know a lot of people will hate me for this, but I’m thinking about hosting two talks:

  • [my organization] is not “doing DevOps.”
  • [my organization] is not doing Continuous Integration (CI).

  Or should I find another organization where there would be fewer people hating me for giving those talks?

  ★

• The Talk Show Remote From WWDC 2021 - Daring Fireball:

  Recently I have been lying to potential employers that I want to become a software engineer like Martin Fowler or DHH. Watching this video reminded me that I want to become a software engineer like Craig.

  Sorry folks.

  ★

• The Testing Hill Tim Bray Would Die On

  Testing in the Twenties - Tim Bray:

  1. Unit tests are an essential investment in your software’s future.
  2. Test coverage data is useful and you should keep an eye on it.
  3. Untested legacy code bases can and should be improved incrementally
  4. Unit tests need to run very quickly with a single IDE key-combo, and it’s perfectly OK to run them every few seconds like a nervous tic.
  5. There’s no room for testing religions; do what works.
  6. Unit tests empower code reviewers.
  7. Integration tests are super important and super hard, particularly in a microservices context.
  8. Integration tests need to pass 100%, it’s not OK for there to be failures that are ignored.
  9. Integration tests need to run “fast enough“.
  10. It’s good for tests to include benchmarks.

  I think we’ve just had a new Testing manifesto. Agree with most of the explanations to those ten points too.

  Update: There is a great comment from Jim:

  I’ve noticed that (the more reasonable of) those of us that are, treat TDD mostly as a design exercise, not a testing one. We just get tests as a bonus. And of course, sometimes the tests need to change, and some I throw away.

  I also do “exploratory testing” when trying out new libraries, techniques etc, especially in spikes. I find it helps to keep the crap tests then, as a warning for later :-)

  Secondly, I think needing to make private methods public in order to test them is a code smell. Almost all the time, there is another class trying to get out. Somewhat more rarely, there is code in private methods that cannot be exercised by calling the public ones, which means there is unnecessary code in the private ones, and it can safely be removed.

  I have very similar thoughts to Jim’s while reading this article.

  We should think of TDD as a helpful practice (for some people) to create well-designed, well-tested code instead of considering it “the best and only way to attain self-testing code.”

  I do make private methods/properties internal to test their internal state sometimes because it’s easier that way. However, I have to think about those cases a lot and also consider them code smells.

  Thanks a lot folks.

  Another update: Very quickly, Mr. Fowler himself steps up and publish his take on the subject.

  And as usual, he points out the exact problem - very clearly with pictures. Please go ahead and read the whole thing since quoting his entire post would be weird.

  Thanks again, folks!

  ★

• 24-inch iMac Color Codes

  --pink: #b72c31;
  --orange: #e36942;
  --yellow: #d48207;
  --green: #10505b;
  --blue: #25476d;
  --purple: #353a71;
  --silver: #c7c8ca;
  --pink-light: #eeb8b0;
  --orange-light: #e9aa95;
  --yellow-light: #eaca96;
  --green-light: #a4beb2;
  --blue-light: #a8bed2;
  --purple-light: #abacca;
  

  Source: Apple

  ★

• Bad software sent postal workers to jail, because no one wanted to admit it could be wrong:

  Janet Skinner said that she was taken away from her two kids for nine months when she was imprisoned, after the software showed a £59,000 shortfall. She also says she lost a job offer because of her criminal conviction. The time she and others like her spent in jail can’t be bought back, and it happened because software was taken at its word.

  […] another woman, who swore she was innocent, was sent to prison for theft while she was pregnant.

  One man reportedly died by suicide after the computer system showed that he had lost almost £100,000. Within a few months, his replacement also faced losses due to discrepancies from the software.

  Horizon (the software) was made by Japanese company Fujitsu.

  Probably out-sourced too.

  This is a programmer’s worst nightmare, but it’s not. This is real life, and we are making software that can cause catastrophic consequences like this for real people everyday.

  The least you can do?

  Test Your Software.

  ★

• Tips For Writing Markdown

  Kevin Bongart (@KevinBongart):

  After 10+ years of using Markdown, it finally clicked that web links usually look like rectangles (on mouse hover), so the text is in brackets. The URL, as an additional detail to what you’re reading, is in parentheses.

  This is so useful for anyone trying to write for the web. Mr. Gruber sure put a lot of thoughts and real life experience into designing the Markdown syntax.

  Kyle Starr in the thread also thinks the image syntax ![ ]( ) looks like an old press camera.

  Thank you folks.

  ★

• Indie Developers And The Lack Of A Price Tag

  The lack of a price tag seems almost criminal - inessential by Brent Simmons:

  I should explain: (NetNewsWire) is better — much better — than it would be if it were a for-pay app. If it were a for-pay app, it would be just me working on it instead of this great team of volunteers. There probably wouldn’t be an iOS version at all: it would be Mac-only. The kind of features I don’t enjoy doing, such as the Twitter and Reddit integration (and others), wouldn’t even exist.

  And it would be slow going. NetNewsWire 5 would have shipped much later than it did, and NetNewsWire 6 would not have shipped until next year, probably.

  Instead, because it’s open source, we have this amazing team of people willing to work on it in their spare time. During a pandemic and everything. They’re bringing you something great out of love, with the goal of writing an app of the highest quality.

  We don’t have to rush and Ship Right Now in order to make our revenue numbers. We don’t have to pick feature X over feature Y because we think it will bring in more conversions. We can care about performance and efficiency; we can say no to things that might have made money but that are outside our vision.

  There’s nothing wrong with commercial software — NetNewsWire was commercial software for many, many years — but it’s also a great freedom to us that it’s not. And it allows us to make something much greater than I would have made all on my own.

  I have a feeling that this is the exact situation that the great text editor TextMate is in, and they are going in this direction as well.

  The sad part is:

  (Why all on my own? Because, these days, a Mac and iOS RSS reader is not going to bring in enough revenue to pay for a team greater than one. And even paying one full salary plus health insurance would have been a hell of a longshot.)

  Anyway, let’s support NetNewsWire. (Don’t send money!)

  ★

• Great Advices From Brent Simmons

  inessential: How NetNewsWire Handles Threading:

  Some developers I’ve known seem to think that being good at concurrency makes them badass. Others seem to think that senior developers must be great at concurrency, and so they should be too.

  But what senior developers are good it is eliminating concurrency as much as possible by developing a simple, easy, consistent model to follow for the app and its components.

  ★

• Programming Is Easy

  

  See also: Common reasons that software projects fail

  ★

• Pleasure Of Programming

  Ori And The Will of the Wisps Switch Analysis: Inside An ‘Impossible’ Port:

  It must be amazing working on this whole thing, the devs making this sensational port, the folks from Digital Foundry making this video - which is the best video from them so far.

  ★

• Common Reasons That Software Projects Fail

  Code Complete: Design in Construction:

  Projects fail most often because of poor requirements, poor planning, or poor management. But when projects do fail for reasons that are primarily technical, the reason is often uncontrolled complexity. The software is allowed to grow so complex that no one really knows what it does. When a project reaches the point at which no one completely understands the impact that code changes in one area will have on other areas, progress grinds to a halt.

  ★

• The Pain Of Offshore Agilists

  Using an Agile Software Process with Offshore Development:

  Because agile development works best with close communication and an open culture, agilists working offshore feel the pain much more than those using plan-driven approaches. But it’s still less pain than the plan-driven methods themselves!

  I can feel the pain myself after just ~3 years in the field.

  ★

• How To Go Fast

  Toyota Production System - Extreme Programming Explained: Embrace Change, Second Edition [Book]:

  If you eliminate enough waste, soon you go faster than the people who are just trying to go fast.

  ★

• Virtual WWDC 12020 Beginning June 22

  Apple Newsroom:

  For the first time, Apple will host its Worldwide Developers Conference virtually, beginning June 22.

  Virtual as a feature, not a bug. Also, fantastic cover image for the event.

  ★

• Working From Home For The First Time

  Today is my first day ever working from home, one of the first things I noticed is that Windows 10 looks very crisp on my Macbook Pro (via remote). I have always know that my work monitor is crap but now it’s clearer than ever before.

  Another thing is that I thought working from home means that you connect to the company VPN and, you know, work from home. According to my company’s policy, we have to keep our work machine on over the weekend, then at home we will remote access to that machine and “work”. I know outsourcing software means security is the top priority but I would argue that if all the source code is on Gitlab, all tasks are on Jira/Confluence, all designs are on Figma, all resources are on AWS already… is there a better way to work?

  ★