It is here.

The first episode looks at Nicola (not Tesla, the other one) which makes electronic/hydrogen vehicles that we will need in the future, the future being absolutely right now.

In the second episode, Grant interviews Massimo Banzi, of Arduino fame.

There are three more episodes coming. Each episode is about 5 minutes long, high production value, interesting interviews. Makes me want to get back to work on that garage door open/closed detecting robot.

cPanel is great because it does things that are critically important in a way that most users can mange.

cPanel sucks because it does that job, sure, but in a way that ends up confusing most users. In other words, the only way to use cPanel unless you already know what you are doing is if you have careful step by step instructions for using cPanel. So, it is only slightly better than the command line.

And now, cPanel has decided to dramatically raise its cost to the extent that most hosts that use cPanel now will have to jettison it or charge more.

I’m letting you know so you can be mad at cPanel. Also, if you know of any OpenSource or reasonably priced alternatives, let’s hear about it.

My personal favorite for alternative: SSH and cli. But I think more is needed.

That is all.

Is that just art that is rendered in raster? Not exactly. Pixel art is the sort of art you draw for digital cartoons or similar things. The skills and tools of making pixel art would apply to designing icons or logos used in electronic products as well.

To demonstrate what pixel art is, I’m including a few examples from the newly published Make Your Own Pixel Art: Create Graphics for Games, Animations, and More! by Jennifer Dawe and Matthew Humphries.

This book will give you an introduction to the tricks of the trade of making technologically simply but artistically potent drawings, including ways to animate them.

The non-OpenSource (boo) software that is used throughout the book is not expensive and is easy to use, and yes, OpenSource alternatives are suggested and briefly discussed. The book relies on Aseprite and Pro Motion, with GraphcsGale (Windows only, boo) being a free alternative.

Techniques covered include shading, texture, proper use of color, motion and animation, and making things look sentient. Apparently, you can make money doing this sort of thing! This book is probably a good investment, at the very least to see if you have the talent and interest.

Author Jennifer Dawe is an animator and character designer who has been a professional pixel artist for the past 15 years. Author Matthew Humphries is Senior Editor at PCMag.com and a professional game designer.

This post — Mechanical Keyboards What Are They And Which One Do You Want — is a little, but not too much, out of date. The basic information is correct. There are one or two more kinds of keys than described, and there are emerging manufacturers that may or may not be making good switches, and there are many more offerings of el-cheapo keyboards. And, still, the DasKeyboard is still one of the better (and more expensive) options.

My Avant Stellar keyboard finally broke in enough places (I’m tough on keyboards) to require major repair or replacement. I looked briefly at really old Northgates (20-30 years old?) on ebay, bid on a few, but was outbid and decided not to spend an exorbitant amount of money on a decades old untested machine. I also realized that I have two computers sitting next to each other, and when I change between them, it feels wrong, because they have two entirely different kinds of keyboards. But, I realized, if I get a new DasKeyboard for my Linux machine, since I have a Mac DasKeyboard on the Mac, then I would quickly become accustomed to switching back and forth and all would be well. So, I got the Das Keyboard Model S Professional Cherry MX Blue for the Linux to match the Das Keyboard Model S Pro for Mac, and now everything is good.

Except possibly one thing. You may recal that I had earlier complained about the font used on the key caps on the DasKeyboards. At the time, I used stick on labels to upgrade the DasKeyboard to how I like it. For some reason, as I sit here typing on the new DasKeyboard with the small typeface that I don’t like much, I’m not bothered by it, so I may not make that change. We’ll see.

So now all is well in keyboard land, and my pile of no longer in use keyboards available for spare parts grows.

They are:

Computing Skills for Biologists: A Toolbox by Stefano Allesina and Madlen Wilmes, Princeton University Press.

Open Science, Open Source, and R, by Andy Wills, Linux Journal

Why OpenSource?

OpenSource science means, among other things, using OpenSource software to do the science. For some aspects of software this is not important. It does not matter too much if a science lab uses Microsoft Word or if they use LibreOffice Write.

However, since it does matter if you use LibreOffice Calc as your spreadsheet, as long as you are eschewing proprietary spreadsheets, you might as well use the OpenSource office package LibreOffice or equivalent, and then use the OpenSource presentation software, word processor, and spreadsheet.

OpenSource programs like Calc, R (a stats package), and OpenSource friendly software development tools like Python and the GPL C Compilers, etc. do matter. Why? Because your science involves calculating things, and software is a magic calculating box. You might be doing actual calculations, or production of graphics, or management of data, or whatever. All of the software that does this stuff is on the surface a black box, and just using it does not give you access to what is happening under the hood.

But, if you use OpenSoucre software, you have both direct and indirect access to the actual technologies that are key to your science project. You can see exactly how the numbers are calculated or the graphic created, if you want to. It might not be easy, but at least you don’t have to worry about the first hurdle in looking under the hood that happens with commercial software: they won’t let you do it.

Direct access to the inner workings of the software you use comes in the form of actually getting involved in the software development and maintenance. For most people, this is not something you are going to do in your scientific endeavor, but you could get involved with some help from a friend or colleague. For example, if you are at a University, there is a good chance that somewhere in your university system there is a computer department that has an involvement in OpenSource software development. See what they are up to, find out what they know about the software you are using. Who knows, maybe you can get a special feature included in your favorite graphics package by helping your new found computer friends cop an internal University grant! You might be surprised as to what is out there, as well as what is in there.

In any event, it is explicitly easy to get involved in OpenSource software projects because they are designed that way. Or, usually are and always should be.

The indirect benefit comes from the simple fact that these projects are OpenSource. Let me give you an example form the non scientific world. (it is a made up example, but it could reflect reality and is highly instructive.)

Say there is an operating system or major piece of software competing in a field of other similar products. Say there is a widely used benchmark standard that compares the applications and ranks them. Some of the different products load up faster than others, and use less RAM. That leaves both time (for you) and RAM (for other applications) that you might value a great deal. All else being equal, pick the software that loads faster in less space, right?

Now imagine a group of trollish deviants meeting in a smoky back room of the evile corporation that makes one of these products. They have discovered that if they leave a dozen key features that all the competitors use out of the loading process, so they load later, they can get a better benchmark. Without those standard components running, the software will load fast and be relatively small. It happens to be the case, however, that once all the features are loaded, this particular product is the slowest of them all, and takes up the most RAM. Also, the process of holding back functionality until it is needed is annoying to the user and sometimes causes memory conflicts, causing crashes.

In one version of this scenario, the concept of selling more of the product by using this performance tilting trick is considered a good idea, and someone might even get a promotion for thinking of it. That would be something that could potentially happen in the world of proprietary software.

In a different version of this scenario the idea gets about as far as the water cooler before it is taken down by a heavy tape dispenser to the head and kicked to death. That would be what would certainly happen in the OpenSource world.

So, go OpenSource! And, read the paper from Linux Journal, which by the way has been producing some great articles lately, on this topic.

The Scientists Workflow and Software

You collect and manage data. You write code to process or analyze data. You use statistical tools to turn data into analytically meaningful numbers. You make graphs and charts. You write stuff and integrate the writing with the pretty pictures, and produce a final product.

The first thing you need to understand if you are developing or enhancing the computer side of your scientific endevour is that you need the basic GNU tools and command line access that comes automatically if you use Linux. You can get the same stuff with a few extra steps if you use Windows. The Apple Mac system is in between with the command line tools already built in, but not quite as in your face available.

You may need to have an understanding of Regular Expressions, and how to use them on the command line (using sed or awk, perhaps) and in programming, perhaps in python.

You will likely want to master the R environment because a) it is cool and powerful and b) a lot of your colleagues use R so you will want to have enough under your belt to share code and data now and then. You will likely want to master Python, which is becoming the default scientific programming language. It is probably true that anything you can do in R you can do in Python using the available tools, but it is also true that the most basic statistical stuff you might be doing is easier in R than Python since R is set up for it. The two systems are relatively easy to use and very powerful, so there is no reason to not have both in your toolbox. If you don’t chose the Python route, you may want to supplement R with gnu plotting tools.

You will need some sort of relational database setup in your lab, some kind of OpenSource SQL lanaguge based system.

You will have to decide on your own if you are into LaTex. If you have no idea what I’m talking about, don’t worry, you don’t need to know. If you do know what I’m talking about, you probably have the need to typeset math inside your publications.

Finally, and of utmost importance, you should be willing to spend the upfront effort making your scientific work flow into scripts. Say you have a machine (or a place on the internet or an email stream if you are working collaboratively) where some raw data spits out. These data need some preliminary messing around with to discard what you don’t want, convert numbers to a proper form, etc. etc. Then, this fixed-up data goes through a series of analyses, possibly several parallel streams of analysis, to produce a set of statistical outputs, tables, graphics, or a new highly transformed data set you send on to someone else.

If this is something you do on a regular basis, and it likely is because your lab or field project is set up to get certain data certain ways, then do certain things to it, then ideally you would set up a script, likely in bash but calling gnu tools like sed or awk, or running Python programs or R programs, and making various intermediate files and final products and stuff. You will want to bother with making the first run of these operations take three times longer to set up, so that all the subsequent runs take one one hundredth of the time to carry out, or can be run unattended.

Nothing, of course, is so simple as I just suggested … you will be changing the scripts and Python programs (and LaTeX specs) frequently, perhaps. Or you might have one big giant complex operation that you only need to run once, but you KNOW it is going to screw up somehow … a value that is entered incorrectly or whatever … so the entire thing you need to do once is actually something you have to do 18 times. So make the whole process a script.

Aside form convenience and efficiency, a script does something else that is vitally important. It documents the process, both for you and others. This alone is probably more important than the convenience part of scripting your science, in many cases.

Being small in a world of largeness

Here is a piece of advice you wont get from anyone else. As you develop your computer working environment, the set of software tools and stuff that you use to run R or Python and all that, you will run into opportunities to install some pretty fancy and sophisticated developments systems that have many cool bells and whistles, but that are really designed for team development of large software projects, and continual maintenance over time of versions of that software as it evolves as a distributed project.

Don’t do that unless you need to. Scientific computing often not that complex or team oriented. Sure, you are working with a team, but probably not a team of a dozen people working on the same set of Python programs. Chances are, much of the code you write is going to be tweaked to be what you need it to be then never change. There are no marketing gurus coming along and asking you to make a different menu system to attract millennials. You are not competing with other products in a market of any sort. You will change your software when your machine breaks and you get a new one, and the new one produces output in a more convenient style than the old one. Or whatever.

In other words, if you are running an enterprise level operation, look into systems like Anaconda. If you are a handful of scientists making and controlling your own workflow, stick with the simple scripts and avoid the snake. The setup and maintenance of an enterprise level system for using R and Python is probably more work before you get your first t-test or histogram than it is worth. This is especially true if you are more or less working on your own.

Culture

Another piece of advice. Some software decisions are based on deeply rooted cultural norms or fetishes that make no sense. I’m an emacs user. This is the most annoying, but also, most powerful, of all text editors. Here is an example of what is annoying about emac. In the late 70s, computer keyboards had a “meta” key (it was actually called that) which is now the alt key. Emacs made use of the metakey. No person has seen or used a metakey since about 1979, but emacs refuses to change its documentation to use the word “alt” for this key. Rather, the documentation says somethin like “here, use the meta key, which on some keyboards is the alt key.” That is a cultural fetish.

Using LaTeX might be a fetish as well. Obliviously. It is possible that for some people, using R is a fetish and they should rethink and switch to using Python for what they are doing. The most dangerous fetish, of course, is using proprietary scientific software because you think only if you pay hundreds of dollars a year to use SPSS or BMD for stats, as opposed to zero dollars a year for R, will your numbers be acceptable. In fact, the reverse is true. Only with an OpenSource stats package can you really be sure how the stats or other values are calculated.

And finally…

And my final piece of advice is to get and use this book: Computing Skills for Biologists: A Toolbox by Allesina and Wilmes.

This book focuses on Python and not R, and covers Latex which, frankly, will not be useful for many. This also means that the regular expression work in the book is not as useful for all applications, as might be the case with a volume like Mastering Regular Expressions. But overall, this volume does a great job of mapping out the landscape of scripting-oriented scientific computing, using excellent examples from biology.

Mastering Regular Expressions can and should be used as a textbook for an advanced high school level course to prep young and upcoming investigators for when they go off and apprentice in labs at the start of their career. It can be used as a textbook in a short seminar in any advanced program to get everyone in a lab on the same page. I suppose it would be treat if Princeton came out with a version for math and physical sciences, or geosciences, but really, this volume can be generalized beyond biology.

Stefano Allesina is a professor in the Department of Ecology and Evolution at the University of Chicago and a deputy editor of PLoS Computational Biology. Madlen Wilmes is a data scientist and web developer.

Knowing how the elements of a program work is fine and dandy, but applying programming concepts to the real world is where the rubber of code meets the reality of … running code, I guess. Impractical Python Projects: Playful Programming Activities to Make You Smarter is full of code examples, and they are said to be impractical, but really, that depends on why you even use computers. For example, one might want to breed rodents of unusual size, or come up with an anagram suitable for a Dark Wizard. Even more useful is calculating the odds of detecting alien civilizations (I for one welcome our hypothetical overlords from elsewhere in the universe). Make a python programmed volcano for your next science project. Seriously, that’s not a bad idea for the kiddo…

To give you an idea, here are the chapters:

Chapter 1: Silly Name Generator
Chapter 2: Finding Palingram Spells
Chapter 3: Solving Anagrams
Chapter 4: Decoding American Civil War Ciphers
Chapter 5: Encoding English Civil War Ciphers
Chapter 6: Writing in Invisible Ink
Chapter 7: Breeding Giant Rats with Genetic Algorithms
Chapter 8: Counting Syllables for Haiku Poetry
Chapter 9: Writing Haiku with Markov Chain Analysis
Chapter 10: Are We Alone? Exploring the Fermi Paradox
Chapter 11: The Monty Hall Problem
Chapter 12: Securing your Nest Egg
Chapter 13: Simulating an Alien Volcano
Chapter 14: Mapping Mars with the Mars Orbiter
Chapter 15: Improving Your Astrophotography with Planet Stacking
Chapter 16: Finding Frauds with Benford’s Law

This book does something else, that not too many coding instruction books do. The author, Lee Vaughan, builds small projects that work, then applies python based methods to analyze the code, showing how the original project had problems of one kind or another, then builds them again. The results are surprising, even spectacular, and very instructive.

The book does assume a basic knowledge of how python works, but that is not hard to get from any of several other books, or on line. Rather than being an introductory text, Vaughan’s project pushes you in interesting directions for solving a diverse set of problems. Most of these “impractical” projects, while themselves being not so useless after all (there are those of us that need to produce or evaluate anagrams now and then, for example) will have parallels to real life projects. For example, the exploration of the Fermi Paradox and Drake Equation can serve as a template for a wide range of simulations, and the section on Benford’s law can, well, help you cheat better on your taxes!

This is just plain a fun book, and it is useful, not impractical.

You are the boss. You want a pile of files to be put away. You could do it yourself, but instead you instruct someone else to do it. There are a lot of them and they are all mixed up. So you write a memo to an employee that says “put the files away” and sis-bam-boom you’re all set.

Or are you?

It turns out that the files fall into four categories, each associated with a different set of file cabinets. All the files have labels with words and numbers on them. One set is filed alphabetically. Two sets are filed by the number that is on the label. The fourth set are stacked in an outbox in any order where they are to be processed by someone else at a later time.

So, if you just say, “file these” a lot of things can go wrong, unless he person who gets the memo knows what to do.

Your memo could read “Find the person who knows how to file stuff. Then have that person file these files properly.” In a computer language, that is a little like loading a library then using instructions from that library to carryout a task in a specific way.

# file.py
import alpha-numeric-filing as fileit

def main():
files.fileit(file)

… or code to that effect.

The point is, telling your underlings to do something only works if the underlings do it correctly. This is also true with computers, where a line of code seems to be instructing the processor, way down deep in the hardware, to do a certain thing, but it may or may not be actually doing that thing.

Computers are famous for making strange and unexpected (to the non-expert) calculations. For example, a computer will calculate the base 10 log of 2 as 0.000029995663981195 off of the actual number because of the way numbers are represented and manipulated inside the machine. So when you ask for that value in a computer program, you are making an incorrect assumption if you think it is being done correctly.

That is a known mathematical phenomenon and not of consequence to most people or most programs, but there may be other issues that are more important and even less predicted. Like the filing problem mentioned above, there may be assumptions built into the deeper level operation of a computer program or script once it is complied or interpreted, linked up with other software it works with, and deployed on this or that machine. This is the difference between working in the area of written code including uncompiled programs or scripts and the deeper binary code that is created by the software that interprets or complies your program.

Practical Binary Analysis: Build Your Own Linux Tools for Binary Instrumentation, Analysis, and Disassembly by Dennis Andriesse (with a foreword by Herbert Bos) is a guide to looking into the binaries created by application-making software. This is a set of approaches to delve into the space in which malware may lurk, bugs may flourish almost invisibly, and inefficiencies may wreak their slow and ponderous havoc.

The book teaches how to:

The most important way in which this book will change your life is that it will allow you to analyze binaries more automatically and with less manual work.

I can not truly evaluate this book because this is way beyond, or maybe, way below (as in down deep in the abyss of computer science where I assume small gnomes still write all the assembler language) my understanding of thing. But the book gains great praise from others, and is a brand new edition.

Dennis Andriesse has a Ph.D. in system and network security and uses binary analysis daily in his research. He is one of the main contributors to PathArmor, a Control-Flow Integrity system that defends against control-flow hijacking attacks such as ROP. Andriesse was also one of the attack developers involved in the takedown of the GameOver Zeus P2P botnet.

What is new in the new Google Chrome 69 Browser?

This new 10th anniversary edition (has it only bee 10 years?), which you can download here, is said to be faster. However, speed is more of a function of your internet connection and computers’ speed, so how much that matters will depend on your situation. In-line results, in the place formerly known as the Address Bar, are new. You’ll see things in there like the actual weather, not just a link to the weather, or say Google believes you have documents or links related to an upcoming trip, and you put the destination city in the search bar … you may get a link to your files. That sort of thing.

Security is improved, but I can’t really say how. Flash is handled differently, more gingerly, so that’s one thing.

The biggest difference, probably, is the overall look and feel It is rounder and flatter, as things are these days. Material design style, for those keeping track. There are more and perhaps better themes, and you can play around more with the background.

There is a thing called Picture in Picture mode. I think this allows you to deploy that annoying feature some web sites already have where a video that is playing follows you around and refuses to go away. Yay!

What’s wrong with this first release of Google Chrome 69?

A variety of things, like downloading certain files instead of using or “playing” them, like web sites that won’t work or that are greyed out. It is actually not worth listing these problems here because even as we speak they are being fixed. Within the last few hours, 40 bugs were fixed, most of which most people didn’t even see.

My biggest concern is that there are URLs I must visit now and then that Google habitually sees as insecure (but they are gateways through which it is difficult to pass, and otherwise do nothing). If the new Google Chrome is super security oriented and not perfected, I may not be able to do certain things. So, I’ll keep a computer with the old Chrome indefinitely just to make sure, once I do upgrade.

I am about to launch two heavily modified or freshly home built computers, and I’m a bit worried that if I do that right now, and install the available version of Chrome, I’m going to have problems. What that really means for me is keeping Firefox on those boxes, just in case!

Why is it called 69?

I believe this is called Chrome 69 simply because it is the 69th version. But I for one do not remember earlier vesions being called by their name so overtly, so I’m wondering if there is another reason. I tried typing “why is it called 69” into Google. I got lots of answers, but not to my specific question.

Desktop

The screen “real estate” that coveres a monitor on which icons may be placed, and which is generally covered up when an application is open.

Desktop

A type of computer which usually includes a “box” containing a CPU, hard drives, and other hardware, a separate keyboard, separate monitor, and so on. Sometimes the monitor and the “box” are integrated.

Desktop

Also called a “Desktop environment,” the main all encompassing user interface associated with a specific distribution of Linux. Examples are “Gnome Desktop” and “KDE” (note that the “K” in KDE originally stood for “kool” so that KDE meant Kool Desktop Environment.” This is a wordplay on the “Common Desktop Environment” or CDE, which was a unix system based on x11 technology. Soon after the name first went into use the meaning “kool” was dropped and everyone tried to forget about it. Some have suggested that KDE is a typical recursive term, like GNU (GNU = “GNU is Not Unix”), and would thus mean “KDE Desktop Environment.”)

Desktop

The surface of a piece of furniture typically with a legwell, drawers, etc., on which one puts a computer for normal use. See also “Lap” and “Laptop”

Desktop

An individual “workspace” consisting of a virtual desktop, icons and other things that go on a desktop, which may or may not be part of a particular desktop environment’s capabilities, allowing a user to expand screen real estate by a factor of how many separate virtual desktops are defined.

I love the way the parrot responds to Alexa’s response by first making bleepy-bloopy techie noises, then imitating the sound of all the manual light switches being thrown.

But wait, there’s more. This parrot made an Alexa shopping list: