Tag Archives: tech

What I find interesting in tech, August 2021

Here’s a cornucopia of things I have found interesting in tech in the last month. As usual, lots of cloud, some Kubernetes, DevOps and software of course, as well as IOT. Grab a drink and read!

Cloud: 

Devops:

Software:

Kubernetes:

Security:

IOT:

Cool stuff:

General

(Photo by Sam Albury on Unsplash )

On the rise and fall and unlikely rise of QR codes


I’ve been a fan of QR codes for a decade. Back then I wrote about how they could be used to tag everything from trees and medic alert bracelets to IOT devices. I thought the sky was the limit for them. I was wrong.

Until this year. As Clive Thompson writes here, the pandemic has been a game changer in causing the resurgence of QR codes. I am glad to see that.

I’d still like to see QR codes everywhere. It would be a way of connecting the virtual world to the real world. Cities could tag streets and neighborhood with QR codes to allow you to get a glimpse of context into where you are standing. If a new building is being built, put a QR code on a sign out front that links to a web site providing greater detail on it. As for historic buildings, why not put a QR code on them that links to their wikipedia page describing the historical significance. Anyway, lots of ways QR codes could enhance our understanding of the world.

Here’s hoping they are here to stay, providing us a way to better navigate our world.

(Photo by Rebecca Hausner on Unsplash )

In praise of e-paper and alternative displays

Here’s three pieces by Max Braun on using alternative displays for information. I think they are great.  For example, I would love to have postersized screen on my wall to read the paper each day.

And this calendar is minimal and cool:

For more on these, see these links:

What I find interesting in tech, November 2020

Kubernetes

Here’s 59 links (!) of things I have found interesting in tech in the last while. It ‘s heavily skewed towards Kubernetes because that’s mostly what I have been involved with. Some stuff on Helm, since I was working on a tricky situation with Helm charts. There’s some docker and Open Shift of course, since it’s related. There’s a few general pieces on cloud. And finally at the end there’s links to a bunch of worthwhile repos.

Almost all of these links are self explanatory. The ones that aren’t…well…few if anyone but me reads these posts anyway. 🙂 Just treat it like a collection of potentially good resources.

  1. How to create custom Helm charts
  2. How to make a Helm chart in 10 minutes | Opensource.com
  3. Basic kubectl and Helm commands for beginners | Opensource.com
  4. A visual guide on troubleshooting Kubernetes deployments
  5. Kubernetes Canary Deployments for User Beta testing | by Damien Marshall | ITNEXT
  6. Hands-on guide: developing & deploying Node.js apps in Kubernetes
  7. Deploying Java Applications with Docker and Kubernetes – O’Reilly
  8. Kubernetes, Kafka Event Sourcing Architecture Patterns, and Use Case Examples – DZone Big Data
  9. 10 most important differences between OpenShift and Kubernetes – cloudowski.com
  10. Node.js in a Kubernets world – IBM Developer
  11. Learn Kubernetes in Under 3 Hours: A Detailed Guide to Orchestrating Containers
  12. Service accounts — Kubernetes on AWS 0.1 documentation
  13. Copy directories and files to and from Kubernetes Container [POD] | by Nilesh Suryavanshi | Medium
  14. Monitoring Kubernetes in Production: How To Guide | Sysdig
  15. Kubernetes Cheat Sheet | Red Hat Developer
  16. Kubernetes In a Nutshell | Enqueue Zero
  17. Kubernetes Deployment in a Nutshell | Clivern
  18. Kubernetes namespaces for beginners | Opensource.com
  19. Level up your use of Helm on Kubernetes with Charts | Opensource.com
  20. Running Solr on Kubernetes
  21. Solr on Kubernetes on Portworx
  22. Zookeeper – Unofficial Kubernetes
  23. Kubernetes for Everyone
  24. Chris Biscardi’s Digital Garden
  25. Istio / Getting Started
  26. How To Set Up a Kubernetes Monitoring Stack with Prometheus, Grafana and Alertmanager on DigitalOcean | DigitalOcean
  27. Kubernetes Ingress Controllers: How to choose the right one: Part 1 | by Eric Liu | ITNEXT
  28. An introduction to Minishift, OpenShift, and IBM Cloud – IBM Developer
  29. How To Set Up an Nginx Ingress on DigitalOcean Kubernetes Using Helm | DigitalOcean
  30. An introduction to Kubernetes.
  31. Health checks in Kubernetes for your Node.js applications – IBM Developer
  32. Beyond the basics with Cloud Foundry – IBM Developer
  33. Build a cloud-native Java app using Codewind and your favorite IDE – IBM Developer
  34. Accelerating the application containerization journey – Cloud computing news
  35. 6 Key Elements for a Successful Cloud Migration | IBM
  36. An introduction to Minishift, OpenShift, and IBM Cloud – IBM Developer
  37. There aren’t enough humans for cloud-native infra. Can DevOps deal? – SiliconANGLE
  38. Leverage deep learning in IBM Cloud Functions – IBM Developer
  39. CloudReady for Home: Free Download — Neverware
  40. Council Post: It’s Time To Accelerate Your Hybrid Or Multicloud Strategy
  41. Getting started with solution tutorials
  42. How to get started with GCP  |  Google Cloud
  43. Setting up Solr Cloud 8.4.1 with Zookeeper 3.5.6 | by Amrit Sarkar | Medium
  44. solr – How to force a leader on SolrCloud? – Stack Overflow
  45. Play with Docker Classroom
  46. Getting any Docker image running in your own OpenShift cluster
  47. Building Docker Images inside Kubernetes | by Vadym Martsynovskyy | Hootsuite Engineering | Medium
  48. Get an IBM MQ queue for development on Windows – IBM Developer
  49. Ultimate Guide to Installing Kafka Docker on Kubernetes – DZone Big Data
  50. Kafka on Kubernetes — a good fit? | by Johann Gyger | Noteworthy – The Journal Blog
  51. How To Install Apache Kafka on Debian 10 | DigitalOcean
  52. Chapter 7. Monitoring and performance – Kafka Streams in Action: Real-time apps and microservices with the Kafka Streams API [Book]
  53. charts/incubator/cassandra at master · helm/charts · GitHub
  54. atlas-helm-chart/charts/zookeeper at master · xmavrck/atlas-helm-chart · GitHub
  55. nhs-app-helm-chart/solr.yaml at master · pajmd/nhs-app-helm-chart · GitHub
  56. GitHub – manjitsin/atlas-helm-chart: Kubernetes Helm Chart to deploy Apache Atlas
  57. GitHub – IBM/Scalable-WordPress-deployment-on-Kubernetes: This code showcases the full power of Kubernetes clusters and shows how can we deploy the world’s most popular website framework on top of world’s most popular container orchestration platform.
  58. A Dockerfile with (almost) all the tools mentioned in Bite Size Networking by Julia Evans · GitHub
  59. GitHub – sburn/docker-apache-atlas: This Apache Atlas is built from the latest release source tarball and patched to be run in a Docker container.

Two good pieces addressing racial inequality in tech


Here are two good pieces addressing racial inequality in tech

  1. If Toronto wants to be a global tech hub, it needs to nurture Black talent | TVO.org
  2. Racial Justice Open Source Projects – Call for Code for Racial Justice – IBM Developer

In my humble and limited opinion, tech has many gaps when it comes to who works in the industry, especially when it comes to women and when it comes to black and indigenous people. Any efforts to address these gaps are a good thing.

(Photo by Christina @ wocintechchat.com on Unsplash)

Quote

The decline of start-up tech in 2020

Is described here: As the Start-Up Boom Deflates, Tech Is Humbled – The New York Times.

Key takeaways:

  • It’s not as bad as the dot com era
  • It should not be expected, given how many duds startup tech has given us lately
  • It may lead to something worse, but my assessment right now is it could signal a correction more than an overall decline

There’s been many stories written about tech lately: that article is a good chance to get an overall assessment as to where tech is now. At least, start up tech.

Quote

Kubernetes Is the Future of Computing?

I hesitate to echo Barron’s here: Kubernetes Is the Future of Computing. Everything You Should Know. – Barron’s because computing is vast, and there is more to computing than Kubernetes. (AI, for one thing.) But Kubernetes is one of the main drivers of change in IT, and more and more people are moving towards it. If you don’t know much about it and you subscribe to Barron’s, I recommend you read their piece. Otherwise Google “kubernetes for business leaders” or “Kubernetes 101” and you’ll find quite a few good pieces on it.

Quote

Moodnotes: an app to document your thoughts and moods


If you are using CBT to deal with your mood, consider this app:  Moodnotes: a  Thought Journal, Mood Diary, CBT App.

It helps you quickly capture your mood, but it also help you deal with distorted thinking that contributes to poor moods or worse.

I am cautious about recommending such apps, because I worry what the app developers will do with the data. I have looked at their privacy policy and it is easy to understand and it says they won’t keep specific data. So I am cautiously recommending it.

Quote

A smart poster that knows the weather (and a great alternative display)

Is this:

It uses smart ink, so it’s low power. But it changes throughout the day, based on the information it gets from the Internet. It looks great, and it’s around $134, which is not bad.

I’d like to see more tech do this. A fine marriage of high tech and aesthetics.

For more information, see A smart poster that knows the weather | Yanko Design

Some thoughts on insurance companies and the use of wearable technology

When it comes to insurance and wearables, I think the effect of these devices will be limited. I think this because:

  1. I don’t believe people are consistent about using wearables. I have been using wearables and fitbits for some time. I believe most people are prone to not wearing them constantly. Inconsistent use will make it harder for insurers to guarantee you a  better rate or for you to achieve one.
  2. You are more likely to wear it and use it when you are trying to keep in shape. If you are not, you will likely not wear it. The insurer can’t know if you are getting out of shape or just no longer wearing it. (I used to use a Nike+ device for running, and I ran consistently, but I did not use the device consistently. Many days and weeks I just didn’t feel like it.) The use of wearables is mostly an upside for you, and of limited value to the insurer.
  3. One reason I gave up on using wearables consistently is that they don’t give you much new information. I walk and exercise consistently and so they often give me the same information consistently. Which means I tend to not wear them often. I don’t need the fitbit to tell me I walked 10,000 steps. I know I did because my commute to and from work plus my lunchtime walk consistently gives me that.
  4. My fitbit scale is great for tracking my weight over time, but an insurer could also just ask me my weight, height and waistline and get a sense of my eligibility for insurance, just like how they ask if I smoke. A very low tech way to measure things. Men with a waist over 40 inches are more prone to heart disease then men with much smaller waists, regardless of what a high tech scale says. A insurer needs a limited number of data points to assess your health risks.
  5. I believe there is limited return for insurers to get this much data. I base this on my current life insurer. I can get life insurance from 1-6X my salary (assuming I pay the corresponding rise in premiums) without providing medical data. They only ask for medical data if I ask for more than 6X. It likely isn’t of benefit for them to process the data for lower amounts, so they proceed without it.
  6. Insurers are data driven, for sure, but I think they are good at picking out a limited number of good numbers to determine what to charge you for insurance. I don’t think the numbers coming back from wearable tech is all that good.

So in short, I don’t believe people or insurers will get much benefit from wearable tech. People will not get breaks on their insurance, and insurers will not be able to reduce their risk substantially with the use of wearables.

In an alternative universe this is the next hot smartphone


I am unexcited about the direction in Smartphone design. The key design idea that less is more in a phone is becoming Less is a Bore. Perhaps that’s why this design of a Blackberry got me thinking about it. While it still has a gorgeous screen, the phone itself is worthy of looking at and touching. It strikes the right balance. The phone as a design object is worthwhile.

It would have been good if Apple had struck out in a new design direction with the iPhone X. Instead they went with Less is More. Instead we have a phone with the Notch and a camera on the back that sticks out. It’s as if Apple would have preferred not to have these cameras and sensors,  so rather than design the phone to incorporate them into the design, they stick out, figuratively and literally. In a few years from now when Apple has gone in a different direction, Apple fans will look back and exclaim how poor that aspect of the phone design is.

As for now, we live in an age where the screen dominates design, from TVs to smartphones. In the future that may change and the technology that we interact with will be contained in objects that have noteworthy design in them.
For more on this beautifully designed phone, see If BlackBerry Ditched the Keyboard | Yanko Design.

The iPhone 8 is really the iCamera 8

iphone
Great review of the latest iPhone*, here: The iPhone 8 is a look into the augmented future of photography | TechCrunch. I had heard that the iPhone 8 had a great new camera, but this article really drives that home.

If you are thinking of getting an “8”, this could be the reason you need. On the other hand, if you rarely take photos or don’t care too much about the quality, I think the case for an upgrade gets weaker.

*  I don’t consider the iPhone X the latest phone so much as a promise of where the iPhone is going. To be honest, I think the iPhone X is as much an attempt to celebrate the 10 years of the iPhone and Steve Jobs’s legacy, not unlike the Twentieth Anniversary Macintosh. Not that there is anything wrong with that.

 

Juicero post-mortem

 

Juicero
The juicero is toast. Not surprising to me: it was a terrible idea.

While the juicero was terrible, this analysis of the engineering behind the juicero is fantastic: Here’s Why Juicero’s Press is So Expensive – Bolt Blog.

Even if you aren’t interested in this device, read this analysis. You will come away with a much better appreciation of all the devices currently in your own life and some of the thinking that goes into making them.

 

ICYMI: What is code, by Paul Ford

Happy Monday! Are you affected by code at work? Of course you are! Do you code at work yourself? Very likely, even if it is to use formulae in a spreadsheet program like Excel (which, years ago, would have required been considered coding). However code affects you, I highly recommend you read this:
Code. It’s a very rich piece on code (i.e. software) and what it means to you (and everyone else).

Among other things, it is brilliantly designed. Lots of hard work went into this piece. If you can’t get started yet this week at work, read this as a research project.

Looking to buy a technical gift for someone (or yourself) ?

Then you need to check out the Wirecutter. It has experts in every area of technology — from headphones to TVs to much more — stating what they think is thebest thing to buy right now. They explain their reasoning, offer alternatives, and best of all, the site is kept up to date. Also, they have links to sites like Amazon and others to let you take the next step and purchase the tech you want.

Why the Surface RT Failed and the iPad Did Not (Not)

Nick Bilton tries to explain the failure of the Surface with one cause, here: Why the Surface RT Failed and the iPad Did Not – NYTimes.com. While I think this is one potential reason, I also think there are many reasons why it failed. Here are some more:

  • Too expensive: comparatively to other tablet devices. Even if it was alot better, customers would be more likely to go with the equally impressive and less costly iPad or Android devices.
  • No need for the product: if the other tablets lacked in some capacity, perhaps the Surface would have taken off. But the needs of tablet users was more than met by what was in the market.
  • Network externalities: what used to work for Microsoft now worked against them. It’s not enough to develop a tablet: you have to develop all the things tablet users expect and support that as well. Otherwise you have to go to the commodity market.

Invalid reasons would be:

  • Microsoft can’t do hardware: Microsoft can do hardware. Their XBOX line in particular is nowhere near the weakling of the Surface or Microsoft’s earlier hardware failure, the Zune.
  • No one can compete with Apple: Google in conjunction with Samsung and others are doing a good job of competing with Apple.
  • There is no room for more hardware in the market: again, Google and others have shown it is possible to compete in this space.

I don’t think Microsoft is done in this space. But I think they may approach it differently. We’ll see in the next two years.