Martin חיים Berlove
creator, thinker, polymath
Summary of Experience
Selected Projects / Achievements / Activities
Calm Speech Project[In Progress]
Goal: Achieve a better society through better communication.
Completed coursework in data science and analytics
A short guide to help people learn new tools and frameworks with less hassle
Received Mongo DB developer certification
A small task list app made using Ruby's Hanami framework
Decided to kill two birds with one stone and make a productivity app for myself while learning a newer framework.
Simple Trello tasklist integration using PHP
Customized Vi[m] themes
Much to my surprise, I've become something of a vim adherent, enough to want my own themes to suit my preferences.
Conceptual game made for Github Game Off 2016
A better way to think about the money you spend
Extensible interface for demonstrating graph theory fundamentals.
Pong clone in JQM that supports touch.
Learning German language, spoken and written
Through the use of Duolingo, textbooks, online tutoring, and immersion, I hope to bring my skills up to a level for day to day communication with native speakers and to read technical papers written in German.
Explorations in music creation
A variety of raytraces for fun and education
Video-based classes on various topics in computing
Recent Writing (@MartinBerlove)
Solution Space: Unexpected Shutdown

You’re in the middle of finishing up an important document, using reference materials scattered across browser tabs, open PDFs, and an email chain — and your computer shuts down.

Whether due to system error or a scheduled mandatory upgrade, unexpected shutdowns represent an exorbitant pain for any user — doubly for so-called “power users” who tend to have dozens of windows and consoles open simultaneously. Losing that context on shutdown can throw you off your game, and cost significant time to get back on track.

Managing this issue differs by system; for instance, macs have a decent feature for reopening windows and programs after a shutdown. What about Windows users? Windows does include a feature to resume open programs on startup, but it’s buggy, inconsistent, and often won’t resume unsaved items the way mac does (even on mac, to be fair, the feature is not perfect).

For me, leveraging a windows/linux dual boot, it’s a big deal. I often switch back and forth between each OS, which requires a shutdown (hibernate is an option — but doesn’t always work cleanly).

After one nuisance of a Blue Screen of Death during the middle of a recording session, I decided to solve this problem for myself.

As I sat down to think about how to fix this, I realized it can’t be one of my bigger projects. A relatively rare problem, it’s not worth it to spend long hours coding a custom solution to tie into the Windows APIs and work 100% perfectly to all my needs.

What I want is something simple — a list of open windows, so that if my open programs fail to resume after a shutdown, I can read off a list of previously open windows and identify what is missing. A matter of moments.

But how to get there? The key factors are as follows:

1 ) Easy to build. I don’t want to spend hours coding. This means either applying an existing solution, or using a point-and-click interface.

2 ) Windows compatibility. Windows has its own APIs for window management, whereas a more universal solution might not work consistently.

3 ) Readable output. I opt to forgo a more complex solution to actually reopen my programs, which in any case might conflict with Window’s own feature to do this. Instead, I just want a list — but that list should be pretty clear so I can see what I’m missing.

What tool or framework meets the criteria noted above?

It’s time to dig out a name I hadn’t thought about in years: AutoIt.

Rather than trying to describe it myself, I’ll let AutoIt’s site do the talking:

AutoIt v3 is … designed for automating the Windows GUI and general scripting … to automate tasks in a way not possible or reliable with other languages.

Most pertinently, AutoIt is simple, works out-of-the-box, and has lots of Windows API tie-ins that make scripting a breeze. It’s not common that I run across an aspect of my daily workflow that requires this kind of automation, so it’s been a while since I’ve used it! But it’s such a simple setup that in literally two minutes, I’ve got it up and running again.

Before I can be sure that AutoIt will fit my needs, it’s important to check how hard it will be to get a list of open windows…

…fortunately, StackOverflow, via a quick Google search, has done the hard work for me.

I try this script out in AutoIt and find that it works. However, it outputs to console, and I need a written list that I can reference. Jumping into the AutoIt documentation, a quick text search in the function reference leads me to a way to write to a file, including a handy example.

It’s a matter of moments to rewrite my script to output to a file using the new example rather than writing to console. I test the script, and it works! I have a document containing a list of all open windows — just what I want.

Now I’m 90% of the way to a solution, but I’m missing one crucial element: the script needs to be run manually, which doesn’t help me if the computer shuts itself down while I’m not looking.

Fortunately, Windows has a way to schedule processes to run automatically via the task scheduler.

I set up a new task which repeats every hour on the hour — you could change this to a different period of time depending on your needs; for me, an hour is about right. Now it just needs something to run. I could have it run the AutoIt script runner and take the script as a parameter, but there’s a cleaner way: AutoIt provides a utility to turn a script into an executable program!

In a matter of moments, I have an executable file that I can set as the action of my new task in the task scheduler.

And we’re done! In something like ten minutes, I went from identifying a nagging problem, through some very basic analysis, to generating a solution. It’s small, it’s easy, it’s not at all demanding on my system’s resources, and now I won’t have to worry about losing control of my open workflow.

Potential Improvements

  • As you might notice if you followed along in practice, the list of windows that gets written to the document includes all the open background tasks, and many redundancies, so that the end list can prove difficult to peruse, and makes for unsightly reading, cluttered with unnecessary information. Paring this down, either via AutoIt’s WinList or an external means like a regex via PowerShell, would lead to a more effective solution.
  • I find my list of open windows really useful, but it would be much more useful to have them open by themselves. AutoIt could almost certainly handle this, but for me, it wasn’t quite worth the effort. By turning off Window’s automatic restoring feature, you could avoid any conflicts, and use only your own solution to restore your workflow.
  • Because a new document is generated every hour, the list will quickly grow and grow. I currently have the documents output to their own subfolder, and they’re fairly small so I don’t need to worry about space constraints, but it would be nice to have a rolling “cleanup” that gets rid of any documents older than, say, thirty days.


As problems go, this was a minor one. As solutions go, I got lucky that such a simple answer could be pulled together. But large or small, the key aspects of solving any such problem generally fall into three categories:

1) Identifying the key problem, and the scope. For me, this meant trading off time for a simpler solution, and realizing what would meet my needs.

2) Awareness of the solution space. There are many ways to solve a problem, but for me, for this issue, AutoIt was the way to go. If I hadn’t known about AutoIt, I might have had a harder time coming up with a solution. However, you can usually preempt such trouble, by—

3) Gathering information efficiently. Once on the trail of the solution, being able to find enough information to build a picture of how to solve the problem is a critical skill, and one that can definitely be developed. In this day and age, Google and other tools often make it child’s play to come up with a mountain of relevant information, such that it’s more important to be able to filter out bad information than to locate good information. But either way, and no matter the means by which you compile the information, thinking critically about what information will lead you on the right path without restricting your vision too narrowly is how you navigate efficiently to a solution.

⇣ expand ⇣⇡ collapse ⇡
Under One Roof: What New Tech Means in the Workplace

In July 1978, the New York Times transitioned from a hot-type to a cold-type system — from cast metal typesetting with red hot metal to the quiet, cool computer-based systems still employed in principle today.

The video exploring the transition between these systems is worth watching if you have the time, for a number of reasons, not the least of which is the view of the modern computer systems put in place.

A number of interesting items jump out in both the old system and the new — including the ferocious speed at which they were able to cast metal — but the most intriguing item was also one of the most minute: a small animation on the new computer systems for the typists. Any time a writer sitting at one of the typist’s terminals finished composing an article, they would press a button to “send” it off to the editor for review. At that point, the article would appear to roll up the screen, curling in at the top as it “left” the typist’s viewscreen and presumably went off to the editor’s terminal.

Of all things, you’d imagine that kind of animation to be a triviality. In a sense, it is — it doesn’t impact the actual production process, nor change the words that are put on the paper. But that fact makes it all the more pertinent in the context of those writers. We’re so adjusted today to minor animations and other decorations used to gloss up the computing systems we use. They’re very easy to add, and half the time we don’t even notice them except when they are absent. But in the ’70s, adding such an animation was no trivial task. The computing power required for that to occur, on each terminal, every time a writer completed a page was an investment, as was the time taken by the system’s programmers to implement it. So why bother? The writers needed to learn a new system anyway; why not let them adjust to thinking about the page they wrote as virtual rather than a physical page delivered to the editor?

There were many adjustments that the writers in that office needed to make: A new keyboard layout, new methods for organizing content on pages, the ins and outs of a software system — for many who had never before touched a computer. Now it would become a part of their daily workflow.

For any typist in that office, the process of turning words into clean, readable, digestible pages of a newspaper was a craft. It’s difficult for us in the age of one-off articles and automated newsletters to think about it this way, but the fundaments of what made a newspaper excel persisted from the old system into the new, and came along with the writers as they transitioned to the new system. It was this sense of artistry and experience that needed preserving in order to achieve success. Not every individual working at the NYT (or other offices, undergoing the same inevitable change) could adjust; it involved a complete readjustment of decades of work experience.

One worker who did make the transition put it so:

I’ve learned the new stuff, the new processes and all, but I’ve been a printer for twenty-six years…six years apprenticeship; twenty years journeyman — and these are words that aren’t just tossed around. They’ve always meant something to us printers.
And it’s inevitable that we’re going to go into computers; all the knowledge I’ve acquired over these twenty-six years is all locked up in a little box now called a computer….

Even those who made the transition, who stuck it out to the new system, who effectively threw out years and decades of accumulated knowledge to make way for technology, felt the impact of what was changing.

That one little animation of a page rolling out of the top of the screen bridged this technological gap. It emphasized for the typists that their jobs were still fundamentally the same: You may sit in a different place, type on a keyboard connected to a computer terminal rather than on a mechanical board, the issues you encounter will be electrical rather than mechanical, but at the end of the day the work you do persists for the same purpose, still goes to the same place, still ends in the same goal.

That is the reason for the animation; that is the reason for the time and money spent implementing a minor flourish— to keep the worker in the game, to help them transition, to subtly but clearly remind them that while the system has changed, the crux and value of their work has not.

It’s a valuable lesson for today’s workplace, which is far more transient than most any workplace in the 1970s when this transition and many similar ones took place. When change comes, it comes as much for the worker as for the work itself. A system that changes isn’t just a swapping out of components, or a financial trade-off, but an impact on the nature and culture of a workplace. Recognizing the value of the experience gathered right under your roof produces a transformative impact on the relationship between the organization and the individuals who work there. An investment in the worker is an investment in the business. The profit of loyalty is significant — and it’s a two-way street.

That same worker quoted above, speaking about how the new computer systems replaced the old ways and would do most of the work, brought it together with one pertinent last statement:

I think probably most jobs are going to end up the same way.

Under One Roof: What New Tech Means in the Workplace was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

⇣ expand ⇣⇡ collapse ⇡
The Telecommute Transition
⇣ expand ⇣⇡ collapse ⇡
Recent Posts (@MB)