Tag Archives: software

It’s winter. Time to curl up with a good…list of tech links :) (What I find interesting in tech January 2024)

500Wow. I have not posted any tech links since last September. Needless to say, I’ve been doing alot of reading on the usual topics, from architecture and cloud to hardware and software. I’ve included many of them in the lists below. There’s a special shout out to COBOL of all things. Is there something on DOOM! in here? Of course there is. Let’s take a look….

Architecture: A mixed bag here, with some focus on enterprise architecture.

Cloud: a number of links on cloud object storage, plus more….

COBOL: COBOL is hot these days. Trust me.

Hardware: mostly but not exclusively on the Raspberry Pi….

Mainframe/middleware: still doing mainframe stuff, but I added on some middleware links….

Linux/Windows: mostly Linux but some of the other OS….

Software: another mixed bag of links…

Misc.:  For all the things that don’t fit anywhere else….also the most fun links….

Thanks for reading this!

Habit List: an app that has really helped me with keeping my habits

If you are looking for an app that can help you form good habits, I highly recommend this one: Habit List

Things I like about it:

  • it is easy to add new habits to your list
  • you can decide the frequency of the habit: daily, weekly, 3 times a week, etc. It’s very flexible
  • it’s quick to update
  • you can track your streaks, completions, and best streaks which I find motivating
  • you can set reminders
  • you can export your data
  • it is priced reasonably: you can track a few habits for free and after that I think it has a one time charge of less than $10. Compared to some apps that want you to pay over $100 / year, it’s a bargain.

Check out the link above for more details. If it sounds good, download it for free and start with a few habits you want to work on. I think you’ll be glad you did.

 

Advent of Code: a great way for coders to celebrate this season

You’ve likely heard of Advent, but have you heard of Advent of Code? Well let the maker of the site, Advent of Code 2023, explain what it is:

Hi! I’m Eric Wastl. I make Advent of Code. I hope you like it! I also made Vanilla JS, PHP Sadness, and lots of other things. You can find me on Twitter, Mastodon, and GitHub. Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like. People use them as interview prep, company training, university coursework, practice problems, a speed contest, or to challenge each other. You don’t need a computer science background to participate – just a little programming knowledge and some problem solving skills will get you pretty far. Nor do you need a fancy computer; every problem has a solution that completes in at most 15 seconds on ten-year-old hardware.

It seems like just the thing for coders of all kinds, from amateurs to professional devs. Check it out. And if you want to get involved from day 1 in 2024, make a note on your calendar (assuming Eric still does it.)

It may be time to ditch Evernote. I went with Joplin and it’s been great

Now that Evernote is all but killing their free plan, you may be considering moving. That was me awhile ago. I loved Evernote, but the restrictions and bloated features made me want to move.

I wasn’t sure what to move to, so I did some research. These two links were especially helpful:

I nixed migrating Evernote to OneNote because I use the latter mostly for work notes. And while I use and love SimpleNote, I like it only for specific purposes. I considered Obsidian, but it seemed more than what I wanted.

In the end I went with Joplin for a few reasons:

  1. Joplin made it easy to move my Evernote material into it.
  2. Joplin can run on my Mac, iPhone and iPad for free.
  3. With Joplin my notes are stored on Dropbox, which I like.
  4. Joplin seemed closest in features to Evernote for me.
  5. With Joplin I can use Markdown if I want.

I haven’t had any problems with Joplin since I moved to it many weeks ago. I kept Evernote on my Phone in case of problems, but I have not used it in ages. After I post this, I think it will be time to delete the app from all my platforms.

I was a big fan of Evernote. It was great. But Joplin is great too, and once you start using it, you won’t turn back.

P.S. Don’t just take my word on it. Read those links, too. You might find you want to go with one of those other tools. I use OneNote and SimpleNote all the time and I highly recommend those, too.

AI scales up and out. Here’s some pieces that shows that.


While there are still prophets and pundits arguing doom and gloom regarding AI, most people and organizations have moved past them and have been adopting the technology widely. Some times that has been good, some times not. To get a sample of how it’s going, here’s a few dozen pieces on AI worth a look:

  1. The WSJ argues that you soon won’t be able to avoid AI at work or at home. It’s true, but so what?
  2. AI is being used to deal with the threat of wildfires. Good. Also good: AI allows farmers to monitor crops in real time. More good AI:  AI used to find antibodies. By the way, here’s a piece on how to turn chatgpt into a chemistry assistant.
  3. A worthwhile piece on AI lawsuits that are coming due to intellectual property rights.
  4. The New York Times has stopped Openai from crawling its site. More on that, here.
  5. Here’s the associated press AI guidelines for journalists.
  6. Students and writers, bookmark this in case you need it: what to do when you’re accused of writing with AI.
  7. Also, what can you do when AI lies about you?
  8. This is dumb: AI builds software under 7 minutes for less than a dollar.
  9. It’s not surprising hackers from lots of security holes in AI.
  10. Take this with a big grain of salt…one of the leaders from Palantir wonders if AI should be compared to atomic energy.
  11. This is bad: how facial recognition tech resulted in a false arrest.
  12. This is not good: a story on using AI to generate books and other junk here.
  13. This is different:  Microsoft Teams is pairing up with Maybelline to provide AI generated beauty filters / virtual makeup.
  14. It’s not news but it is interesting that NVIDIA is a hot company now due to AI. See more about that, here.
  15. Maybe chatgpt and other AI will just be a tool to do inefficient things efficiently.
  16. A thoughtful piece on powering generative AI and large language models with hybrid cloud with a surprise ending, from one of the senior leaders in my group at IBM.

(Photo: link to image in the NVIDIA story. By Philip Cheung for The New York Times)

My IT Beach Reads this summer :) (What I find interesting in tech September 2023)


Yes, this is the stuff I read for fun. Not on the beach, but at least in a comfy chair out in the hot sunny weather. 🙂

Architecture links: mostly my IT architecture reading was AWS related this summer, but not all of it.

Cloud links: a mixed bag of things, all good.

Ops links: I’ve been consulting with clients on operations work, among other things, so here’s  pieces on AIOps, DevOps and more that I thought were good:

Software links: mostly dashboard related, since I was working on…dashboards.

Finally: here’s a mix bag of things, quantum and otherwise, that I enjoyed.

Will there be Doom? (What I find interesting in hardware/software in tech Jul 2023)

While my last few posts on IT have been work related, most of these are on hardware and software and tend to be more hobby and fun related.

Hardware links:

Software links:

Hope something there was useful! As always, thanks for reading!

P.S. Before I forget… here’s a piece on how a hacker brought Doom to a payment terminal. Love it!

 

If you want to get a better understanding of generative AI, it pays to see what the New York Times and Bloomberg are up to

One of the problems with generative AI like ChatGPT is it makes you think it is magical. You type in some prompt, it comes back with a complex answer, the next thing you know, you are thinking this thing is smarter than a human. It doesn’t help that there is so much hype surrounding the technology. All of this can make you think it’s supernatural.

Well, it isn’t. It’s simply good IT. It consists of data, hardware and software, just like any other IT. To get a better appreciation of the ordinary nature of that, it helps to look at two recent examples: the AI the New York Times recently built and the AI Bloomberg just built.

It’s best to start with what the Times built. They used software called nanoGPT (karpathy/nanoGPT: The simplest, fastest repository for training/finetuning medium-sized GPTs) and took the works of Jane Austen, Shakespeare and more to build a chatGPT-like program on their laptops. Then they walked through the steps of getting it working, here: Let Us Show You How GPT Works — Using Jane Austen – The New York Times. It works pretty well after much much training. Obviously it is not as massive or sophisticated as ChatGPT, but after reading the article, you will have a better sense of how this technology works, and why it’s impressive but not magical.

After that, I recommend reading more about BloombergGPT. Their press release states:

Bloomberg today released a research paper detailing the development of BloombergGPT, a new large-scale generative artificial intelligence (AI) model. This large language model (LLM) has been specifically trained on a wide range of financial data to support a diverse set of natural language processing (NLP) tasks within the financial industry.

You can find a link to that research paper, here:  BloombergGPT: A Large Language Model for Finance. What I liked about that paper is it walks through the approach they took, the data they used, and the technology deployed to make their model. Even better, they talk about how it is currently succeeding and what some of the limits of it are.

I’m happy that both these companies have been good about sharing what they are doing with this technology. I might even try and use an old laptop to build my own AI. I mean who wouldn’t benefit from tapping into the genius of Shakespeare or Jane Austen.

For more on what Bloomberg is doing, see this: Bloomberg plans to integrate GPT-style A.I. into its terminal

 

More reasons why ChatGPT is not going to replace coders

I have been arguing recently about the limits of the current AI and why it is not going to take over the job of coding yet. I am not alone in this regard. Clive Thompson, who knows a lot about the topic, recently wrote this: Why ChatGPT Won’t Replace Coders Just Yet. Among other reasons, the “‘bullshit’ problem turns up in code, too”. I recommend you read Clive’s take on the subject. And after you read that, check out his book, “Coders”. You can order it, here, from his publisher. I think it’s a classic and one of the best things written on software.

Paul Kedrosky & Eric Norlin of SKV know nothing about software and you should ignore them

Last week Paul Kedrosky & Eric Norlin of SKV wrote this piece, Society’s Technical Debt and Software’s Gutenberg Moment, and several smart people I follow seemed to like this and think it something worthwhile. It’s not.

It’s not worthwhile because Kedrosky and Norlin seem to know little if anything about software. Specifically, they don’t seem to know anything about:

  • software development
  • the nature of programming or coding
  • technical debt
  • the total cost of software

Let me wade through their grand and woolly pronouncements and focus on that.

They don’t understand software development: For Kedrosky and Norlin, what software engineers do is predictable and grammatical. (See chart, top right).

To understand why that is wrong, we need to step back. The first part of software development and software engineering should start with requirements. It is a very hard and very human thing to gather those requirements, analyze them, and then design a system around them that meets the needs of the person(s) with the requirements. See where architects are in that chart? In the Disordered and Ad hoc part in the bottom left. Good IT architects and business analysts and software engineers also reside there, at least in the first phase of software development. To get to the predictable and grammatical section which comes in later phases should take a lot of work. It can be difficult and time consuming. That is why software development can be expensive. (Unless you do it poorly: then you get a bunch of crappy code that is hard to maintain or has to be dramatically refactored and rewritten because of the actual technical debt you incurred by rushing it out the door.)

Kedrosky and Norlin seem to exclude that from the role of software engineering. For them, software engineering seems to be primarily writing software. Coding in other words. Let’s ignore the costs of designing the code, testing the code, deploying the code, operating the code, and fixing the code. Let’s assume the bulk of the cost is in writing the code and the goal is to reduce that cost to zero.

That not just my assumption: it seems to be their assumption, too. They state: “Startups spend millions to hire engineers; large companies continue spending millions keeping them around. And, while markets have clearing prices, where supply and demand meet up, we still know that when wages stay higher than comparable positions in other sectors, less of the goods gets produced than is societally desirable. In this case, that underproduced good is…software”.

Perhaps that is how they do things in San Francisco, but the rest of the world has moved on from that model ages ago. There are reasons that countries like India have become powerhouses in terms of software development: they are good software developers and they are relatively low cost. So when they say: “software is chugging along, producing the same thing in ways that mostly wouldn’t seem vastly different to developers doing the same things decades ago….(with) hands pounding out code on keyboards”, they are wrong because the nature of developing software has changed. And one of the way it has changed is that the vast majority of software is written in places that have the lowest cost software developers. So when they say “that software cannot reach its fullest potential without escaping the shackles of the software industry, with its high costs, and, yes, relatively low productivity”, they seem to be locked in a model where software is written they way it is in Silicon Valley by Stanford educated software engineers. The model does not match the real world of software development. Already the bulk of the cost in writing code in most of the world has been reduced not to zero, but to a very small number compared to the cost of writing code in Silicon Valley or North America. Those costs have been wrung out.

They don’t understand coding: Kedrosky and Norlin state:A software industry where anyone can write software, can do it for pennies, and can do it as easily as speaking or writing text, is a transformative moment”. In their piece they use an example of AI writing some Python code that can “open a text file and get rid of all the emojis, except for one I like, and then save it again”. Even they know this is “a trivial, boring and stupid example” and say “it’s not complex code”.

Here’s the problem with writing code at least with the current AI. There are at least three difficulties that AI code generators suffers from: triviality, incorrectness, and prompt skill.

First, the problem of triviality. It’s true: AI is good at making trivial code. It’s hard to know how machine learning software produces this trivial code, but it’s likely because there are lots of examples of such code on the Internet for them to train on. If you need trivial code, AI can quickly produce it.

That said, you don’t need AI to produce trivial code. The Internet is full of it. (How do you think the AI learned to code?) If someone who is not a software developer wants to learn how to write trivial code they can just as easily go to a site like w3schools.com and get it. Anyone can also copy and paste that code and it too will run. And with a tutorial site like w3schools.com the explanation for the code you see will be correct, unlike some of the answers I’ve received from AI.

But what about non-trivial code? That’s where we run into the problem of  incorrectness. If someone prompts AI for code (trivial or non-trivial) they have no way of knowing it is correct, short of running it. AI can produce code quickly and easily for you, but if it is incorrect then you have to debug it. And debugging is a non-trivial skill. The more complex or more general you make your request, the more buggy the code will likely be, and the more effort and skill you have to contribute to make it work.

You might say: incorrectness can be dealt with by better prompting skills. That’s a big assumption, but let’s say it’s true. Now you get to the third problem. To get correct and non-trivial outputs — if you can get it at all, you have to craft really good prompts. That’s not a skill anyone will have. You will have to develop specific skills — prompt engineering skills — to be able to have the AI write python or Go or whatever computer language you need. At that point the prompt to produce that code is a form of code itself.

You might push back and say: sure, the prompts might be complex, but it is less complicated than the actual software I produce. And that leads to the next problem: technical debt.

They don’t understand technical debt: when it comes to technical debt, Kedrosky and Norlin have two problems. First, they don’t understand the idea of technical debt! In the beginning of their piece they state: “Software production has been too complex and expensive for too long, which has caused us to underproduce software for decades, resulting in immense, society-wide technical debt.”

That’s not how those of us in the IT community define it.  Technical debt is not a lack of software supply. Even Wikipedia knows better: “In software development, technical debt (also known as design debtor code debt) is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time”. THAT is technical debt.

One of the things I do in my work is assess technical debt, either in legacy systems or new systems. My belief is that once AI can produce code that is non-trivial and correct and based on prompts, we are going to get an explosion of technical debt. We are going to get code that appears to solve a problem and do so with a volume of python (or Java or Go or what have you) that the prompt engineer generated and does not understand. It will be like copy and paste code amplified. Years from now people will look at all this AI generated code and wonder why it is the way it is and why it works the way it does. It will take a bunch of counter AI to translate this code into something understandable, if that will even be possible. Meanwhile companies will be burdened with higher levels of technical debt accelerated by the use of AI developed software. AI is going to make things much worse, if anything.

They don’t understand the total cost of software:  Kedrosky and Norlin included this fantasy chart in their piece.

First off, most people or companies purchase software, not software engineers. That’s the better comparison to hardware.  And if you do replace “Software engineers” with software, then in certain areas of software this chart has already happened. The cost of software has been driven to zero.

What drove this? Not AI. Two big things that drove this are open source and app stores.

In many cases, open source eliminated the (licensing) cost of software to zero. For example, when the web first took off in the 90s, I recall Netscape sold their web server software for $10,000. Now? You can download and run free web server software like nginx on a Raspberry Pi for free. Heck can write your own web server using node.js.

Likewise with app stores. If you wanted to buy software for your PC in the 80s or 90s, you had to pay significantly more than 99 cents for it. It certainly was not free. But the app stores drove the expectation people had that software should be free or practically free. And that expectation drove down the cost of software.

Yet despite developments like open source and app stores driving the cost of software close to zero, people are organizations are still paying plenty for the “free” software. And you will too with AI software, whether it’s commercial software or software for your personal use.

I believe that if you have AI generating tons of free personal software, then you will get a glut of crappy apps and other software tools. If you think it’s hard to determine good personal software now, wait until that happens. There will still be good software, but to develop that will cost money, and that money will be recovered somehow, just like it is today with free apps with in app purchases or apps that steal your personal information and sell it to others. And people will still pay for software from companies like Adobe. They are paying for quality.

Likewise with commercial software. There is tons of open source software out there. Most of it is wisely avoided in commercial settings. However the good stuff is used and it is indeed free to licence and use.

However the total cost of software is more than the licencing cost. Bad AI software will need more capacity to run and more people to support, just like bad open source does. And good AI software will need people and services to keep it going, just like good open source does. Some form of operations, even if it is AIOps (another cost), will need expensive humans to insure the increasing levels of quality required.

So AI can churn out an tons of free software. But the total cost of such software will go elsewhere.

To summarize, producing good software is hard. It’s hard to figure out what is required, and it is hard to design and built and run it to do what is required.  Likewise, understanding software is hard. It’s called code for a reason. Bad code is tough to figure out, but even good code that is out of date or used incorrectly can have problems and solving those problems is hard. And last, free software has other costs associated with it.

P.S. It’s very hard to keep up and counter all the hot takes on what AI is going to do for the world. Most of them I just let slide or let others better than me deal with. But I wanted to address this piece in particular, since it seemed influential and un-countered.

P.S.S. Beside all that above, they also made some statements that just had me wondering what they were thinking. For example, when they wrote: “This technical debt is about to contract in a dramatic, economy-wide fashion as the cost and complexity of software production collapses, releasing a wave of innovation.” Pure hype.

Or this : “Software is misunderstood. It can feel like a discrete thing, something with which we interact. But, really, it is the intrusion into our world of something very alien. It is the strange interaction of electricity, semiconductors, and instructions, all of which somehow magically control objects that range from screens to robots to phones, to medical devices, laptops, and a bewildering multitude of other things.” I mean, what is that all about?

And this:  “The current generation of AI models are a missile aimed, however unintentionally, directly at software production itself”. Pure bombast.

Or this hype: “They are “toys” in that they are able to produce snippets of code for real people, especially non-coders, that one incredibly small group would have thought trivial, and another immense group would have thought impossible. That. Changes. Everything.”

And this is flat up wrong: “This is just the beginning (and it will only get better). It’s possible to write almost every sort of code with such technologies, from microservices joining together various web services (a task for which you might previously have paid a developer $10,000 on Upwork) to an entire mobile app (a task that might cost you $20,000 to $50,000 or more).”

 

 

 

What is AI Winter all about and why do people who’ve worked in AI tend to talk about it?

It might surprise people, but work in AI has been going on for some time. In fact it started as early as the mid-1950s. In the 50s until the 70s, “computers were solving algebra word problems, proving theorems in geometry and learning to speak English”. They were nothing like OpenAI’s ChatGPT, but they were impressive in their own way. Just like now, people were thinking the sky’s the limit.

Then three things happened: the first AI winter from 1974 until 1980, the boom years from 1980-1987, and then the next AI winter from 1987-1993. I was swept up in the second AI winter, and like the first one, there was a combination of hitting a wall in terms of what the technology could do followed by a drying up of funding.

During the boom times it seemed like there would be no stopping AI and it would eventually be able to do everything humans can do and more. It feels that way now with the current AI boom. People like OpenAI and others are saying the sky’s the limit and nothing is impossible. But just like in the previous boom eras, I think the current AI boom will hit a wall with the technology (we are seeing some of it already). At that point we may see a reduction in funding from companies like Microsoft and Google and more (just like how we are seeing a drawback from them on voice recognition technology like Alexa and Siri).

So yes, the current AI technology is exciting. And yes, it seems like there is no end to what it can do. But I think we will get another AI winter sooner than later, and during this time work will continue in the AI space but you’ll no longer be reading news about it daily. The AI effect will also occur and the work being done by people like OpenAI will just get incorporated into the everyday tools we use, just like autocorrect and image recognition is no just something we take for granted.

P.S. If you are interested in the history of the second AI winter, this piece is good.

What is the AI effect and why should you care?

Since there is so much talk about AI now, I think it is good for people to be familiar with some key ideas concerning AI. One of these is the AI effect. The cool AI you are using now, be it ChatGPT or DALL-E or something else, will eventually get incorporated into some commonplace piece of IT and you won’t even think much of it. You certainly won’t be reading about it everywhere. If anything you and I will complain about it, much like we complain about autocorrect.

So what is the AI Effect? As Wikipedia explains:

The AI effect” is that line of thinking, the tendency to redefine AI to mean: “AI is anything that has not been done yet.” This is the common public misperception, that as soon as AI successfully solves a problem, that solution method is no longer within the domain of AI. Geist credits John McCarthy giving this phenomenon its name, the “AI effect”.

McCorduck calls it an “odd paradox” that “practical AI successes, computational programs that actually achieved intelligent behavior, were soon assimilated into whatever application domain they were found to be useful in, and became silent partners alongside other problem-solving approaches, which left AI researchers to deal only with the ‘failures’, the tough nuts that couldn’t yet be cracked.”[5]

It’s true. Many things over the years that were once thought of as AI are now considered simply software or hardware, if we even think of them at all.  Whether it is winning at chess, recognizing your voice, or recognizing text in an images, these things are commonplace now, but were lofty goals for AI researchers once.

The AI effect is a key idea to keep in mind when people are hyping any new AI as the thing that will change everything. If the new AI becomes useful, we will likely stop thinking it is AI.

For more on the topic, see: AI effect – Wikipedia

UGC (user generated content) is a sucker’s game. We should resolve to be less suckers in 2023

I started to think of UGC when I read that tweet last night.

We don’t talk about UGC much anymore. We take it for granted since it is so ubiquitous. Any time we use social media we are creating UGC. But it’s not limited to site like Twitter or Instagram. Web site like Behance and GitHub are also repositories of UGC. Even Google Docs and Spotify are ways for people to generate content (a spreadsheet is UGC for Google to mine, just like a playlist is.)

When platforms came along for us to post our words and images, we embraced them. Even when we knew they were being exploited for advertising, many of us shrugged and accepted it as a deal: we get free platforms in exchange for our attention and content.

Recently though it’s gotten more exploitive. Companies like OpenAI and others are scrapping all our UGC from the web and turning it into data sets. Facial recognition software is turning our selfies into ways to track us. Never mind all the listening devices we let into our houses (“Hey Google, are you recording all my comings and goings?”…probably)

Given that, we should resolve to be smarter about our UGC in 2023. Always consider what you are sharing, and find ways to limit it if you can. Indeed give yourself some boundaries so that when the next company comes along with vowel problems (looking at you, Trackt) and asks for our data, we say no thanks.

We can’t stop companies from taking advantage of the things we share. So let’s aim to share things wisely and in a limited way.

What I find interesting in tech and can tell you about, Dec 2022


Time once again to show what IT stuff I’ve been doing in the last few months. Some of it I can’t include here due to confidentiality reasons, and there’s some things I want to write about separately. The rest is below and worth checking out.

Software: I’ve been doing some python programming lately, so I found these useful: How you can get your browser history via a python library. Also How to Create Your Own Google Chrome Extension...I’ve been wanting to do this. I used this tutorial recently to build a simple stopwatch With Javascript. Relatedly, here’s a  Free Countdown Timer for Your Website.

I’ve been looking into PyQT for a number of reasons so I found these good: How to Install PyQt for Python in MacOS?, and Python PyQt5 Tutorial – Example and Applications, and pyqt statusbar – Python Tutorial.

Here’s some useful git stuff: Merge Strategies in Git and  best practices on rolling out code scanning at enterprise scale.

Now useful but  cool: matrix webcam. Also this is a cool shell.

A thoughtful piece on DevOps metrics. As for this, DevOps is Bullshit, can’t say I agree.

Finally, I’ve been getting into Neo4J and found this helpful:  Neo4j and graph databases: Getting started.

Hardware/Pi: is this the next new thing: stretchable display? This fast charger is also fun. Game fans, take note: Steam is coming to Chromebooks. 

This is good:  iphone 14 is the most repairable since iphone 7. This is awesome: this retro punk nixie wristwatch actually uses authentic nixie tubes to tell the time. This is handy:  13 great arduino projects to try.

I love this:  Nerdy Hanukkah Card! I also love the idea of making a Raspberry Pi-powered radio. More on that here: at Instructables. Also a good project: How to use Google Assistant on the Raspberry Pi.

Cloud: Here’s some AWS help:  choosing an aws container service to run your modern application, and pointing your Namecheap Domain Name to AWS Linux, and db2 and amazon web services better together.

Some IBM Cloud help: share resources across your ibm cloud accounts, and migrating a large database into ibm cloud databases. Also: Get started with IBM Wazi as a Service.

Some other interesting essays on cloud:

Misc: RIP Kathleen Booth, inventor of Assembly Language. Same for another giant, Frederick P Brooks.

The future is weird:  bereal app gets real roasted with memes and gifs are cringe and for boomers giphy claims.

This surprised me:  amazon alexa is a colossal failure on pace to lose 10 billion this year. In other news, here’s a review of amazon halo rise.

Stratechery by Ben Thompson is always worth a read. Here’s they are on Microsoft Full Circle.

Here’s three stories. One on Zoho (how zoho became 1b company without a dime of external investment), one on Uber (uber says compromised credentials of a contractor led to data breach) and one on Sobeys (inside turmoil sobeys ransomware attack)

 

The history of people asking: is technology X going to replace programmers?

Recently Nature (of all publications) asked the clickbait-y question:
Are ChatGPT and AlphaCode going to replace programmers?  It then quickly states: “OpenAI and DeepMind systems can now produce meaningful lines of code, but software engineers shouldn’t switch careers quite yet.” Then why even ask the question? It goes on to say: Deepmind, a part of Google, “published its results in Science, showing that AlphaCode beat about half of humans at code competitions”.

Regardless of what you think about that article in Nature, here’s the thing to always keep in mind: technology X has been coming along to replace programmers forever.  We had machine code that was replaced with assembler language. We had Assembler language replaced with higher level languages like Fortran. We had a wealth of more sophisticated programming languages come on to the scene. In addition, programming tools like IDEs have come along to save the day and make programming easier for programmers. Yet we still have not lost the need for programmers to write programs.

Programming is still about taking what people want the computer to do and codifying it in a language that the computer understands. In other words: programming. As long as that code is required for computers to do what humans want, there will always be programmers.

Here’s another thing to consider: code is a more efficient way to communicate to a computer. I can write in English “count all the entries in this column from row 2 to 100 if the entry equals the word ‘arts'” or I can write in (Excel) code “=countif(A2:A100,”arts”)”. That efficiency will likely mean that coding will be around for quite some time yet. And people doing that coding will be programming, even if they don’t consider themselves programmers.

So no, Alphacode is not going to replace programmers and programming. It might replace some of the task of what some of them currently do. But programmers and programming will be around for some time to come.

(I like the image above because it captures how the software design and development process is a complex thing, and not just a matter of writing a bunch of code. A lot of thought goes into developing something like a smart phone application, and that thought results in code that results in a good app.)

PlantUML: not just for UML. Also good for Gantt Charts, Mindmaps, etc


If you are an IT architect or specialist, you may have used PlantUML. I have and I really like it: It makes doing technical diagrams dead easy.

What I would like you to know about are non-UML capabilities of the tool. PlantUML has the capability to draw Gantt charts and Mindmaps. You can quickly write out your plans and ideas and PlantUML will convert them into the diagram you want. It’s fantastic and I highly recommend it. If you use Visual Studio Code from Microsoft, plug PlantUML into it and you can get your diagrams made that way. But the PlantUML website can also do the job.

For more on this, go to the sections on Gantt charts or mindmaps.

 

 

 

Paper Macs! Doom on Doom! Build a Voight-Kampff machine! And more (What I find interesting in tech, Sept. 2022)

Here’s 70+ links of things I have found interesting in tech in the last while. It’s a real mix this time, but still contains a good chunk on cloud, hardware and software. Some good stuff on UML, Pi and Doom as well. (Love Doom.) Dig in!

Cloud: here’s a dozen good pieces I recommend on cloud computing…

  1. I think hybrid cloud is the future of cloud computing for big orgs, and IBM does too:  IBM doubles down on hybrid cloud
  2. Not to be confused with multicloud: Multicloud Explained: A cheat sheet | TechRepublic
  3. Speaking of that, here’s 3 multicloud lessons for cloud architects | InfoWorld
  4. Relatedly, Vendors keep misusing the “cloud native” label. Customers may not care. You should care, though.
  5. Cloud Foundry used to be the future, but now it’s time for this:  Migrating off of cloud foundry.
  6. I always find these RCAs good:  Details of the Cloudflare outage on July 2 2019
  7. Speaking of outages: Heat waves take out cloud data centers
  8. Google Gsuite: now with a fee. Good luck with that, Google.
  9. Is your app resilient? Consider this four step approach to verifying the resiliency of cloud native applications
  10. If you are an AWS/Oracle user:  using aws backup and oracle rman for backup restore of oracle databases on amazon ec2.
  11. Good tips:  How to add a custom domain to GitHub Pages with Namecheap – Focalise
  12. Good argument:  Rural carriers: We need more subsidies to build 5G

Software: here’s a mix of software pieces, from how to write good bash to how to run good scrums….

  1. Is Internet Explorer dead? Nope!  IE lives! In Korea.
  2. For bootstrap noobs:  Bootstrap tutorials
  3. Fun to consider:  How is computer programming different today than 20 years ago?
  4. Helpful:  Using Loops In Bash – Earthly Blog
  5. More bash goodness:  Bash – Earthly Blog
  6. Related:  Good SED advice
  7. Some python help:  Automate Internet Life With Python | Hackaday
  8. More python:  Analyze Your Amazon Data with Python.
  9. I found this useful indeed:  Google API’s and python
  10. Load testing vs. stress testing: What are the main differences? Don’t confuse them.
  11. Good IFTTT guide:  Send me new jobs available every Monday – IFTTT
  12. Intriguing:   marcoarment/S3.php 
  13. Deploy any static site to GitHub Pages
  14. For fans of either: Visual studio and Terraform
  15. My friend Carl wrote this and it’s good:  The basics of scrum 

UML: I’ve been doing solution architecture lately, and as a result I have been using Visio and PlantUML. I love the latter and found some good links regarding it.

  1. I love PlantUML. Here’s some links on how to use it with Microsoft’s Visual Studio Code:  PlantUML – Visual Studio Marketplace.
  2. and here  UML Made Easy with PlantUML & VS Code – CodeProject
  3. PlantUML and YAML:  https://plantuml.com/yaml
  4. PlantUML and Sequence Diagrams
  5. More on  Sequence Diagram syntax and features

Hardware: here’s some good (and not so good) hardware stories….

  1. This is cool:  teenage engineering google pixel pocket operator
  2. Also cool:  paper thin retro macintosh comes with an e ink display and runs on a raspberry pi (Image on Top of this post!)
  3. Robots:  Roomba Amazon Astro and the future of home robots
  4. Macbook problems:  Macbook Air m2 slow ssd read write speeds testing benchmark 
  5. More Macbook problems:  Macbook repair program: FAIL
  6. Not great:  Starlink loses its shine
  7. A really dumb idea: the switchbot door lock
  8. Finally:  The 20 Most Influential PCs of the Past 40 Years


Pi: I still love the Raspberry Pi, and I want to do more with them soon.

  1. Nice to see this:Raspberry Pi Pico W: your $6 IoT platform – Raspberry Pi
  2. Related:  How to Connect Your Raspberry Pi Pico W to Twitter via IFTTT | Tom’s Hardware
  3. How cool is this?  LISP on Raspberry Pi
  4. Awesome: make your own VK Machine:  Cool Pi Project (image above)

Sensors: one thing I was going to do with a Pi is build a CO2 meter to check on air flow. However the sensor most used for this, the MQ-135, is not all that great. It’s a problem with cheap sensors in general: you just don’t get good results. To see what I mean, read these links:

  1. BUILD YOUR HOME CO2 METER
  2. MQ-135 Gas Sensor with Arduino Code and Circuit Diagram
  3. Measure CO2 with MQ-135 and Arduino Uno – Rob’s blog
  4. Measuring CO2 with MQ135
  5. Air Pollution Monitoring and Alert System Using Arduino and MQ135

Doom! I love stories of how people port the game DOOM onto weird devices. Stories like these….

  1. So many different ports!  Weird devices that run DOOM
  2. Cool!  Even DOOM Can Now Run DOOM! | Hackaday
  3. More on that:  Run Doom inside Doom!

Kubernetes: Still keeping up my reading on K8S. For example:

  1. You’ve written a kubernetes native application here is how openshift helps you to run develop build and deliver it securely.
  2. Benefits of Kubernetes 

Twitter: I don’t know about you, but I’ve gotten tired of the drama around Elon Musk wanting to buy twitter. However I had a recent spasm where I was reading somewhat on it. Here’s what I read:

  1. Twitter, Musk and Mudge
  2. More on Zatko
  3. Also  Zatko
  4. More on Twitter
  5. Whistleblower: Twitter misled investors FTC and underplayed spam issues. Ok, that’s enough.

Finally: 

  1. Beware Tiktok!  TikTok’s In-App Browser Includes Code That Can Monitor Your Keystrokes. These special browsers have to go.
  2. A bad use of AI in France:  taxing pool owners with hidden pools. It’s bad because the success rate is poor.
  3. Lots of good tech articles at Earthly Blog
  4. Lots of good tutorials at Earthly Blog too.
  5. How do I link my domain to GitHub Pages – Domains – Namecheap.com
  6. Mark Zuckerberg braces Meta employees for “intense period”. That’s a shame, said no on.
  7. Updated: Hardware vendor differences led to Rogers outage says Rogers CTO. More on that Rogers outage.
  8. How to:  Fine-Tune and Prune Your Phone’x Contacts List from The New York Times. Useful
  9. Also useful:  4 iPhone and Android Tricks You May Not Know About – The New York Times
  10. Good to know:  How Updates in iOS 16 and Android 13 Will Change Your Phone – The New York Times
  11. Charge your phone differently:  Phone charging.
  12. Canadian orgs struggle with  Ransomware still.
  13. Apple expands commitment to protect users from mercenary spyware. Good.
  14. Related:  84 scam apps still active on App Store’s steal over $100 million annually

Devs! Could your next online database be a spreadsheet?

If the thought of your next online database being a spreadsheet sounds ridiculous, consider this. Yes, I know, there are times when the only thing that will do the job for you is a highly scalable, highly available relational database. Certainly, there are other times when a NoSQL database with millions of records is the only way to go. That aside, there is likely many times when you need to store one table with hundreds of records or less. In that case, consider using an online spreadsheet from someone like Google.

If you write code to store data in a spreadsheet, one of the key advantages is that you and others can then interact with that data via spreadsheet software. You don’t have to run special ETL programs to get that data there. You have all the power you need. Plus the code to interact with something like Google Sheets is much simpler than the code to interact with something like AWS’s DynamoDB. I know…I have done both.

For more on this, check this out:Google Sheets API using Python : Complete 2021 Guide. It could be just the thing you need.

How to Download Apps on Your Old iPad and iPhone in 2022

If you happen to have an old iPad and you are thinking of using it, you will find this post of interest.

Like you, I have a very old iPad. It still works fine. However, one of the problems with old iPads is that Apple limits them in terms of upgrading the iPads operating system (iOS). My device cannot upgrade past iOS 9.

The problem with having an older version of iOS is this: if you try and download apps for it from the App Store, you will get message after message saying this application needs a later iOS to download. There are a few apps that you can still download directly, but not many, and not the common ones you likely use and want.

There is a work around for this problem. (I found out about it through the video below.) First, you download the apps you want on a iOS device that has a new OS. I did this on my iPhone. Then you go to your old iPad and look for apps you purchased. Voila, the app you just downloaded is there. NOW, when you try to download it, the App Store will say you don’t have the right iOS, BUT it will ask if you want to download a backlevelled version. You say YES and now you have the app running on your iPad.

This will only work for apps that have been around for a long time. So I was able to download apps like Twitter and CNN, but not Disney+. Still you can get quite a few apps downloaded that way, and suddenly mine (and soon your) iPad is much more useful.

For more on this, watch the video.

Thanks, Jishan.

 

Kubernetes and Clouds and much more (What I find interesting in tech, July 2022)


Since April, here are a ton of links I found useful while doing my work. Lots of good stuff on Kubernetes and Cloud (both IBM’s and AWS’s); some cool hardware links; some worthwhile software links. Plus other things! Check it out.

Kubernetes: plenty of good things here to explore if you are doing things with Kubernetes like I was:

Terraform: Relatedly, I was doing work with Terraform and these were useful:

IBM Cloud: one of the two clouds I have been working with. Alot of the work was Kubernetes on IBM Cloud so you’ll see some overlap:

AWS: I work on alot of cloud providers. Mostly IBM Cloud but others like AWS

Software: some of these were work related, but some are more hobby oriented.

Hardware: the pickings are few here

Finally: here are an odd assortment of things worthwhile:

What I find interesting in tech in general, Apr 2022


Well, I didn’t expect this week to be “what I find interesting in IT Week” , but here we are! I hope you have found it all useful. While the other posts were specific, these are of a general nature. From weird cool stuff to mainframes to iphones to architecture. Dig in!

IT Architecture: Here’s some tools you IT architects can use:

Cloud: some cloud related stuff:

Programming: here’s some things software and hardware folks might find interesting:

Finally: here’s some links that need to be seen without falling into a particular category:

What are NFRs (non-functional requirements) and why should you care?


If you have any role in the design of an IT system, you should care about NFRs.  As this piece (Nonfunctional requirements: A checklist – IBM Cloud Architecture Center), states:

Defining and addressing the nonfunctional requirements (NFRs) for a system are among the most important of a software architect’s responsibilities. NFRs are the system quality attributes for a system, as distinct from the functional requirements, which detail a system’s business features and capabilities.

Examples of NFRs include key concepts such as reliability, performance, scalability, and security. NFRs are cross-cutting in nature and affect multiple aspects of a system’s architecture. It’s important to articulate and address the NFRs early in the project lifecycle and to keep them under review as the system is produced. To help with that task, you can use the following checklist of key NFRs. The checklist designed to be consulted when you define and evolve a system’s architecture.

The bold text is key. NFRs describe the qualities your system should have. You have functional requirements and you have quality requirements (i.e. , NFRs). Any system design needs to address both.

The number of specified NFRs your system can have are endless. Three of the key ones found at the top of that list are:

Those three are typically covered in any system design I work on. The piece goes on with a great rundown on the various NFRs you’d expect to address in most system architectures.

Three NFRs missing from that list that I think are important and that I would ask you to consider are:

  • Accuracy
  • Maintainability (related to complexity)
  • Cost

There is often a tradeoff with accuracy and other NFRs, such as performance. To gain better performance, data will often be cached and served up even when it is out of date (i.e., inaccurate). That may be fine. But accuracy should always be taken into account and not just assumed.

Maintainability is often ignored, but it is key for the long term success of a system. Two examples of this. One, developers will sometimes not externalize values in their code; changes to the code require a fix and an outage. That is less maintainable than code with external values in a simple text file that can be changed on the fly. Two, code that is not well documented and not peer reviewed will be harder to maintain. Externalization, code reviews and documentation are examples of maintainability requirements you may have and should have for your IT system.

Cost is an important NFR because it causes tradeoffs with most other NFRs. For example, without cost considerations, stakeholders might have availability requirements that are for 99.99999….. It’s only when cost (and complexity and maintainability) become factors do we see often see availability (and other NFRs) scale back.

Finally, NFRs are not just for software architects: they are for everyone. In fact, I wish the term “non-functional requirement” was replaced with “quality requirement”. However I suspect software architects — for whom functional requirements are key — came up with that term, so we all have to live with it. When you think of NFRs, think Quality Requirements. Everyone involved in the design of an IT system wants it to have good quality. Understanding the NFRs/QRs are key to this.

 

What I learned writing web scrapers last week


I started writing web scrapers last week. If you don’t know, web scraper code can read web pages on the Internet and pull information from them.

I have to thank the Ontario Minister of Health for prompting me to do this. The Minister used to share COVID-19 information on twitter, but then chose recently to no longer do that. You can come to your own conclusions as to why she stopped. As for me, I was irritated by the move. Enough so that I decided to get the information and publish it myself.

Fortunately I had two things to start with. One, this great book: Automate the Boring Stuff with Python. There is a chapter in there on how to scrape web pages using Python and something called Beautiful Soup. Two, I had the minister’s own web site: https://covid-19.ontario.ca/. It had the data I wanted right there! I wrote a little program called covid.py to scrape the data from the page and put it all on one line of output which I share on twitter every day.

Emboldened by my success, I decided to write more code like this. The challenge is finding a web page where the data is clearly marked by some standard HTML. For example, the COVID data I wanted is associated with paragraph HTML tag and it has a class label of  covid-data-block__title and covid-data-block__data. Easy.

My next bit of code was obit.py: this program scrapes the SaltWire web site (Cape Breton Post) for obituaries listed there, and writes it out into HTML. Hey, it’s weird, but again the web pages are easy to scrape. And  it’s an easy way to read my hometown’s obits to see if any of my family or friends have died. Like the Covid data, the obit’s were associated with some html, this time it was a div statement of class sw-obit-list__item. Bingo, I had my ID to get the data.

My last bit of code was somewhat different. The web page I was scraping was on the web but instead of HTML it was a CSV file. In this case I wrote a program called icu.sh to get the latest ICU information on the province of Ontario. (I am concerned Covid is going to come roaring back and the ICUs will fill up again.) ICU.sh runs a curl command and in conjunction with the tail command gets the latest ICU data from an online CSV file. ICU.sh then calls a python program to parse that CSV data and get the ICU information I want.

I learned several lessons from writing this code. First, when it comes to scraping HTML, it’s necessary that the page is well formed and consistent. In the past I tried scraping complex web pages that were not and I failed. With the COVID data and the obituary data,  those pages were that way and I succeeded. Second, not all scraping is going to be from HTML pages: sometimes there will be CSV or other files. Be prepared to deal with the format you are given. Third, once you have the data, decide how you want to publish / present it. For the COVID and ICU data, I present them in a simple manner on twitter. Just the facts, but facts I want to share. For the obit data, that is just fun and for myself. For that, I spit it into a temporary HTML file and open it in a browser to review.

If you want to see the code I wrote, you can go to my repo in Github. Feel free to fork the code and make something of your own. If you want to see some data you might want to play with, Toronto has an open data site, here. Good luck!

 

Some good links on how to learn Python

A friend asked me for some help when it comes to learning Python. I put together this list for him, but it’s good for anyone wanting to learn the computer language.

  1. Why Learn Python
  2. Automate the boring stuff with python. A great book!
  3. Learn python in 24 hours. Another book. Also great.
  4. Learn python in 10 minutes
  5. Good doc on python
  6. Learn Python the hard way
  7. How to make a web app using Flask and Python
  8. How to build a twitter app in python
  9. Become a More Efficient Python Programmer

There are so many great resources on the Internet concerning Python. I could easily triple the size of this list. Start with these: you’ll find the rest soon enough.

(Image from Free Code Camp, which also has good links worth reviewing.)

What programming language should you learn? (2022 edition)

The best programming languages to learn in 2022, according to TechRepublic are these:

It’s interesting to see how things have changed. Back in 2015 when I wrote about this, Java was 1st and Python was in 4th. Javascript was 8th! I am not surprised by this.

Java and the C languages will always be good to know. But if you want to be marketable, learn some Python and Javascript.

In praise of the the post-it note (and Clive Thompson)

post it notes
First up, the post it note. Clive has done a great job of taking something we likely all take for granted and making us think about it in a way that we can really appreciate its value. He does it here specifically with the Post-It note: 13 Ways Of Looking At A Post-It Note | by Clive Thompson | Nov, 2021 | Medium

He’s been doing it for many other topics too. Here’s just one example: Tiny Books an Incredibly Long Piano and Why Are Boss Fights So Damn Hard? .

Basically what I am saying is you should subscribe to his newsletter. He’s been on fire with it recently. He says it is a good way to procrastinate. I say it is a good way to learn about all sorts of interesting aspects of the world.

Write down on a post-it note: Subscribe to Clive’s newsletter. Better yet, just go off and do it. You’ll be glad you did.

(Photo by Kelly Sikkema on Unsplash )

If you are writing a bash script to call a curl command and you want to pass variable values to it, read this…

CodingImage
If you are writing a bash script to call a curl command and you want to pass variable values to it, you may find a hard time determining how to go about it. I did!! I consulting with lots of pages, and nothing seemed to tell me what I want.

Here’s what I eventually did.

Take this example. I am using curl to call the sendgrid API, as you can see below. (I don’t have all the variables, but they were all strings like THESUBJECT and THECONTENT.).

The trick is in the use of single and double quotes. For the variables, they are in double quotes. But notice the use of single and double quotes in the curl command:


TOYOU="noone@gmail.com"
THESUBJECT="once again!"
THECONTENT="Looks good!"
curl --request POST --url https://api.sendgrid.com/v3/mail/send \
--header 'Authorization: Bearer '$AUTH_TOKEN \
-H 'Content-Type: application/json' \
--data '{"personalizations": [{"to": [{"email": '\"$TOYOU\"'}]}],"from": {"email": '\"$FROMME\"'}, "subject": '\""$THESUBJECT"\"', "content": [{"type": "text/plain", "value": '\""$THECONTENT"\"' }]}'

Let’s look at the variables in that curl command.

$AUTH_TOKEN has no quotes around it. In fact, it is up against a single quote on its left. That single quote ends the string Authorization: Bearer and let’s the script fill in the value of $AUTH_TOKEN.

Now look at $TOYOU AND $FROMME. Both of those variables have no blanks in them. So there is a single quote-slash-double quote on the left and a slash-double quote-single quote to the right.

that is different than $THESUBJECT and $THECONTENT. Those strings have blanks in them. For them, there is a single quote-slash-double quote-double quote to the left of them and a double quote-slash-double quote-single quote to the right.

It’s crazy but true. Good luck with it!

(Photo by Shahadat Rahman on Unsplash )

Five digital tools to help you with Kanban (plus one analog tool)

Last week I extolled the virtues of Kanban. If you are looking to grab some tech to run yours from, here are 5 open-source kanban boards to help you get and stay on task from TechRepublic. I’ve used one of them (Kanboard, seen above) and liked it. Check them out and see which one works best for you.

If analog is more your thing, consider this tool featured on Yanko design:

You can easily work this into a Kanban type tracker. Plus it looks cool.

For more on it, see it here.

If you use Chrome as your regular browser, read this and make it better

If you use Chrome as your main browser, you owe it to yourself to read this:  11 of the Best Free Extensions for Google Chrome.

I’ve used a number of them and continue to use Momentum and Grammarly. They make it a better tool.

P.S. And speaking of making tools work better, if you want to have better search results from Google in Chrome, read this: 20 Google Search Tips to Use Google More Efficiently

It’s 2021. Why are you still using spreadsheets to manage your project plans? Use this instead

It’s 2021 and I still see people managing projects using Excel spreadsheets. Sure you CAN do it, but you can do better. I am a fan of OpenProj and I use it often. If that is not for you, consider this online version: Build Gantt Charts Online.

What I like about these tools is you can tie tasks together which have dependencies (as shown in the image). This is very helpful and something not easy to do with spreadsheets.

Speadsheets are great for many things: for managing projects, use a better tool.

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 )

What I found interesting in tech, July 2021

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.

Raspberry Pi / Pico: I have been interested in doing work with the Raspberry Pi Pico, so here are some links I liked:
Raspberry Pi Pico: Programming with the Affordable Microcontroller and Getting started with Raspberry Pi Pico – Control LED brightness with PWM | Raspberry Pi Projects and How to Use an OLED Display With Raspberry Pi Pico | Tom’s Hardware.

I am interested in getting bluetooth working with my Raspberry Pi Pico, so I am reading things like Bluetooth serial communication with Mac, JY-MCU Bluetooth and Arduino | Cy-View and How to: Setup a bluetooth connection between Arduino and a PC/Mac | ./notes and Cheap BlueTooth Buttons and Linux – Terence Eden’s Blog

Not a Pico, but I am also interested in doing work with the ATTTiny 85 chip, so I saved this: How to Program an ATtiny 85 Digispark : 8 Steps – Instructables

Here’s two projects I am interested in. Using a Pico to press a key on the Mac using bluetooth: How to run an AppleScript with a keyboard shortcut on macOS while here is a fun project – Making an Email-Powered E-Paper Picture Frame

Here’s some cool MIDI projects with a Pico: this one, NEW GUIDE: Modal MIDI Keyboard @adafruit @johnedgarpark #adafruit #midi « Adafruit Industries – Makers, hackers, artists, designers and engineers, this Code the Modal MIDI Controller | Modal MIDI Keyboard | Adafruit Learning System, and this Build smart, custom mechanical keyboards for MIDI – or really tiny Ableton Live control – CDM Create Digital Music

Kubernetes/OpenShift / Containers: I’ve been doing more and more work on K8S and OpenShift and found these useful…

Cloud: some advanced cloud knowledge here:

Software Development: here’s some random dev links:

 

 

General: finally here are some interesting links on IT in general:

(Image: via NYT piece on mesh)

In praise of spreadsheets (and some new ways for you to use them)

Excel
Let’s face it: there is no better tool than Excel/spreadsheet software when it comes to managing information. New tools come out all the time, and yet people still depend on this workhorse software to get the job done.

At least it is for me. If that’s you too, then you might be interested in what they have over at Vertex42.com, including these three tools:

  1. Free Gantt Chart Template for Excel
  2. Project Timeline Template for Excel
  3. Savings Snowball Calculator

Of course Google Sheets are also great. Whatever you use, check out that site for some good tools and ideas.

On Microsoft Frontpage: a history not just of a product, but the early days of the web

Microsoft Front Page

I found this piece on Microsoft FrontPage fascinating.  I remember when it first came out: it was a great tool if you wanted to develop for the web. While serious people went with Adobe products, FrontPage made developing web page easier for the rest of us. If you want to learn about the early days of the Web, or if you want to see what well designed software looks like (even if it seems very clunky with that Windows XP interfact), I recommend you read it.

You can actually still download it, here. Now should you? No. Read the sections of the article subtitled “Bad” and “Ugly” to see why.

 

Small Victories, or how to build your own website very simply

You need to build a web site? Consider Small Victories. As they say:

Small Victories takes files in a Dropbox folder and turns them into a website.

Best of all, they can help you build a variety of different sites, from a blog to a home page to e-commerce.

The site explains it very well, so visit Small Victories and see how it’s done.

Found via Swiss Miss. Thanks, Tina!

Quote

What is the equivalent of “Hello, World” for github?


This: Hello World · GitHub Guides.

If you wanted to learn how to use GitHub but felt unsure or anxious, this is a nice little tutorial on how to do it. You don’t need additional tools or deep skills or even be a programmer.

Well worth a visit.

(Image by Richy Great)

Quote

Remember Blackberry?

You don’t see too many BlackBerry mobile phones any more. But that doesn’t mean the end of BlackBerry the company. As you can see from this, they are alive and well making technology for automakers: BlackBerry QNX now in 175 million cars | IT Business

Here’s some key facts:

BlackBerry says its QNX suite is now in 175 million cars, up from the 150 million it announced at CES this year.

The BlackBerry QNX for automotive is a suite of embedded software solutions, including operating systems and middleware, as well as a host of security solutions that protects the vehicle’s systems from cybersecurity attacks. Vehicle manufacturers that don’t want to build their own secure operating systems can use BlackBerry’s QNX operating systems and frameworks to build their ADAS systems.

 

Quote

Tools to help you deal with anxiety, during a pandemic, or otherwise

I think this is a terrible headline, which is too bad, because there is much to take away from this piece:  How to stay sane when the world’s going mad | MIT Technology Review

There are tools and advice in there, including this:

  • Notice when you are worrying, and be kind and compassionate to yourself. This is a difficult time; it makes sense that you might be more anxious.
  • Focus on what’s in your control. Work out what is a hypothetical worry (you cannot do anything about it) and what is a real problem (needs a solution now).
  • Refocus on the present moment. Focus on your breath, or on using your five senses.
  • Engage in activities that you find meaningful and enjoyable. That could include music, walking, reading, baths, household tasks, or calls with friends and family.
  • Notice and limit your worry triggers. If the news is making you anxious, limit your consumption.
  • Practice gratitude. List the things you were grateful for that day: for example, “The sun was shining.”
  • Keep a routine, and stay mentally and physically active.

 

Quote

You may be working from home for awhile. Here are some tools to help you stay focused

This is actually a great looking set of tools to help you work from home: Eight apps to help you stay focused when working from home – The Globe and Mail

Normally when I see such a list — and there have been many — I see the same tools over and over again. Not with this list. Moreover, they are a diverse set of tools to help with various difficulties when you work from home.

Have a look. I’d be surprised if there isn’t one there you could use.

Quote

On specific Agile (software development) traps

There’s much positive to be said about the benefits of Agile software development, and the shift of software development teams is one sign that many feel this way.

However, I think there are some limits to Agile, and this leads teams to fall into certain traps over and over. Indeed, the Wikipedia page highlights a common criticism of Agile, namely:

Lack of overall product design
A goal of agile software development is to focus more on producing working software and less on documentation. This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation. However, this does not justify completely doing without any analysis or design at all. Failure to pay attention to design can cause a team to proceed rapidly at first but then to have significant rework required as they attempt to scale up the system. One of the key features of agile software development is that it is iterative. When done correctly design emerges as the system is developed and commonalities and opportunities for re-use are discovered.

Now, it’s not the case that teams either do design or not. But I have seen that there are a number of specific traps bigger that Agile teams fall into that arise from lack of design. These traps arise from making tactical or limited decisions outside of a larger framework or structure, which isn’t surprising since Agile followers are guided by the principles that the “best architectures, requirements, and designs emerge from self-organizing teams” and “working software is the primary measure of progress”. Unfortunately what I’ve seen that lead to is:

  • Poor middleware/database system decisions: with this trap, you get teams making a decision on deploying a specific middleware package or database system that will support the software development they are doing. However, while that may be great for the Dev, it may not be great for the Ops. If you have enough teams making tactical decisions, you may end up with a more complex system than is necessary and greater technical debt that you want. Once you get enough data into your database systems, trying to reverse the decision may result not result not only in new development and testing, but a small (or not so small) migration project as well.
  • Poor infrastructure decisions: likewise, with this Agile trap I have seen teams using IaaS pick different images to deploy their software onto. Like the database problem, developers may choose one operating system (e.g. Windows) over another (e.g. Debian) because they are comfortable with the former, even if the production environment is more of the latter. The result can be your organization ending up with multiple VMs with many different operating systems to support and thereby increasing the operational costs of the system.
  • Poor application framework decisions: I see less of this one, although it can happen where teams pick an assortment of application frameworks to use in creating their software, and as with middleware and infrastructure, this will drive up the support effort down the road.

Given these traps, I think the way to avoid them is to inject some specific design phases into the overall software development lifecycle. One way to do that is to revisit a software development lifecycle (see diagram below) used by practitioners at IBM and documented in places like this IBM redbook. It has a waterfall quality about it, but it doesn’t have to be limited to waterfall type projects. It can be highly iterative.

The lifecycle process is shown here (taken from the redbook):

 

GSMethod

The part of the lifecycle in the large box is iterative and not all that different from an agile sprint.  But here you take time to explicitly make design / architecture decisions before building  software. You continue to iterate while making important design decisions before building.

Now, before you start your iterative software development lifecycle, you should need to  make specific architectural decisions. You should make these specific decisions in the solution outline and macro design phase. For smaller teams, these two phases may blend into one. But it is here in solution outline and macro design where you make decisions that are fundamental to the overall solution.

For example, in solution outline you could make overall architectural decisions about the application architecture, the choice of infrastructure technology, what application frameworks are the target for the team. These overall architectural decisions guide the dev, test and ops teams in the future. You may also decide to park some of these decisions in order to do further discovery.  Macro design could be next, where each of the dev teams make certain design decisions about their technology choices before they proceed with their iterations. As they are building and deploying code, they can run into issues where they need to make further design decisions, either due to problems that arise or technology choices that have to finally be made: and this is where the micro design phase is useful.  Micro design decisions could be quickly made, or they may require spikes and proof of concepts before proceeding. Or there could be no decisions to be made at all.  The main thing is more design checkpoints are built into the development lifecycle, which can result in less complexity, less maintainability costs, and less technical debt down the road. What you lose in velocity you can make up in overall lower TCO (total cost of ownership).

There is a risks to this type of approach as well. For example, if the project gets hung up with trying to make design decisions instead of gather requirements and making working software. The key stakeholders need to be aware of this and push on the design teams to prevent that from happening. If anything, it can help the key stakeholders better understand the risks before getting too far down the road in terms of developing software. Overall I think the risks are worth it if it helps you avoid these common agile traps.