Wednesday, April 10, 2019

Google AutoML And Thinking Machines

Google AutoML & Thinking Machines

After attending a machine learning presentation I got the chance to talk to the presenter about AutoML. He said that it is out-performing a lot of data scientists at Google. Which really peaked my interest. I asked him if the software was similar to the software Daniel Hillis wrote back in the '90s to generate code that was out-performing human coders (see The Pattern on the Stone). Sadly, he had no idea who Daniel Hillis is. I think the idea of software generated code never caught on because no one could understand why it was faster but everyone could agree that it wasn't safe because it was so difficult to decide if it would always work correctly. Which brings to mind the question - is AutoML safe? Will it create bias because the data is formatted a certain way?

I look forward to learning more about how AutoML works. I'm also interested in learning how to use AutoML but am vastly more interested in its internals.

Thursday, March 28, 2019

Monitoring Matters

My mornings start with me reading my Google news feed. This morning included a story about Wow Air closing. Approximately four hours later I ran the following Google query:


Imagine my surprise to see a large travel company still running ads for Wow Air. At this point operations had been ceased for around ten hours. Ads for such a competitive market would probably cost one to six dollars per click. And with Wow Air being in the news curious people probably clicked that ad to see what was being sold in addition to people who wanted to travel to Iceland. I clicked it. It was a branded page but when I dug into the options Wow Air was already removed from the list of carriers. This highlights the different speeds with with different departments react to changes. And moreso, it highlights the lack of communication in businesses. Someone, probably many someones, knew that Wow Air was no more so they removed it as a flight carrier option. They did not, it would seem, reach out to Marketing and say, "Hey, you'll want to disable your ads." This is the downside of work silos. It would never have crossed their minds that such a thing could be helpful. Besides it is not their job...

For small businesses and account managers, it often isn't a problem to respond to an issue within 24 hours. Something I use and have shared with some account managers is Google Alerts. This works well but can take a day to get an alert. Basically, you get notified if some keywords you specify are referenced when a new webpage gets indexed. This might not help you if an existing webpage is updated. It depends on whether your keywords didn't use to match but do after the webpage is re-indexed.

For things that need immediate handling when there is a change then that usually requires being proactive. For example, there are lots of services that will notify you within a few minutes that a webpage has changed. In this case, if you are the person handling Ads for Wow Air then you would probably want to know anytime the main landing page changes. Most of the time the changes won't matter to you but they could reflect a need to update your ads or in an extreme case - this case - the need to disable your ads. Several years ago, I had a job where it was very helpful for me to know when and if a set of services were down or had changed. I used https://www.runscope.com/ to notify me if a set of tests didn't pass.

As a software engineer, it is really valuable to listen to the problems that your coworkers are facing, even the ones in different departments. You might hear an account manager complain about how much of a hassle it is to constantly check for press releases that relate to any of their accounts. Then you can helpfully share that you use Feedly to monitor the release of new webcomics and they could use it to get notified of press releases or anything online.

Tuesday, March 26, 2019

Your Brain At Work

Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day LongYour Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long by David Rock
My rating: 3 of 5 stars

Great advice but the presentation via examples made the material hard to endure. Also the examples were so extreme I found them to be a bit off-putting. They followed a pattern of saying that without the miracle techniques being presented in the book you would end up poor and unloved and it would be your own fault. But by applying the strategies from the book you would be successful in business, friendship, parenthood, and you would have more sex.

Don't get me wrong. There is undoubtable good advice in this book but results will vary. Some of the strategies will likely offend other people because they might feel that they are being manipulated. Read this book with a large pinch of salt.

View all my reviews

Monday, March 18, 2019

Inspect Code

Batman and Sherlock Holmes

Inspection of software design and code was first proposed by Michael Fagan in "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal, July 1976. Inspection can account for as much as 82 percent of all errors found in software. Inspection is much better than testing for finding errors. Define criteria for completing an inspection. Keep track of the types of errors found through inspection. Fagan's inspections consume approximately 15 percent of development resources with a net reduction in total development cost of 25 to 30 percent.

A project schedule should account for the time to inspect, and correct, every component. It might seem that a project cannot tolerate such "luxuries." However, inspection should not be considered a luxury. Data has shown that you can even reduce the time to test by 50 to 90 percent. If that's not incentive, I don't know what could be. By the way, there is a wealth of support data and tips on how to do inspections well in "Key Lessons in Achieving Widespread Inspection Use," IEEE Software, July 1994 by R. Grady and T. VanSlack.

Wednesday, March 13, 2019

Smoke Gets In Your Eyes

Smoke Gets in Your Eyes: And Other Lessons from the CrematorySmoke Gets in Your Eyes: And Other Lessons from the Crematory by Caitlin Doughty
My rating: 5 of 5 stars

A fascinating book with a lot to teach. I wouldn't recommend it for someone who is young. There are a lot of the lessons are hard ones. However, I wonder if it should be required reading for an adult or a kid in high school.

View all my reviews

Hand-Test Every Component

Handcrafted logo - premium quality

It might take 30 minutes to test a software component by hand with a few simple test cases. Do it! I am suggesting this in addition to, not in lieu of, the more thorough computer-based unit testing that is already being performed. What is the cost? Just 30 minutes. What is the alternative? Save 30 minutes now, proceed with unit, integration, and system testing. The system fails. Three to four person days are spent trying to isolate the cause of the failure. A half-dozen components are isolated as possible candidates. Each is given to its developers for further examination. Each candidate spends 30 minutes testing the component by hand with a few simple test cases. In short, 30 minutes are less than three to four person days plus 6 x 30 minutes.

Another reason to perform routine manual testing is that it identifies components that need to be updated. All your builds and automated tests will pass and not complain with outdated tech. But when developers have to manually test a component with an outdated build or libraries, they will complain and get it updated. Which will keep the software relevant.


Reference:
Ledgard, H., Programming Proverbs, Rochelle Park, NJ: Hayden Book Company, 1975.

Tuesday, March 12, 2019

Document Before You Start Coding

Wizard writing

This advice will seem strange to some readers, but it becomes natural after being practiced for a while. Comment Before You Finalize Your Code explained why a programmer should document his or her code before finishing it. Document Before You Start Coding goes one step further: Programmers should document their code before starting to code!

After performing detailed design on a component [that is, documenting its external interface and its algorithm(s)], write your inline comments. Most of these inline comments will be nothing other than the previously documented interface and algorithm. Put these comments through the compiler to make sure you haven't done anything silly (like omitting a comment delimiter). Then convert each line of comment into a corresponding program segment. (Note: If you end up with one line of code per comment, you probably specified your algorithm with too much detail.) You'll find debugging goes a lot smoother.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Friday, March 08, 2019

Kiss My Asterisk

Kiss My Asterisk: A Feisty Guide to Punctuation and GrammarKiss My Asterisk: A Feisty Guide to Punctuation and Grammar by Jenny Baranick
My rating: 4 of 5 stars

A fun way to brush up on grammar rules. Kiss My Asterisk is written such that each chapter is standalone. You can read it out of order or spread reading it over several months and you won't miss anything. This makes it great for focusing on specific areas, as a doctor's office book, coffee table book, etc.

View all my reviews

Tuesday, February 26, 2019

Barking Up The Wrong Tree

Barking Up the Wrong Tree: The Surprising Science Behind Why Everything You Know About Success Is (Mostly) WrongBarking Up the Wrong Tree: The Surprising Science Behind Why Everything You Know About Success Is (Mostly) Wrong by Eric Barker
My rating: 5 of 5 stars

An interesting collection of facts, research, and stories about success. For example,

"Distractions literally make you Stupid.

Students whose classroom was situated near a noisy railway line ended up academically a full year behind students with a quiet classroom. When the noise was dampened, the performance difference vanished. Offices aren't much different. Research shows that the most productive computer programmers have one thing in common. It's not experience, salary, or hours spent on a project. They had employers who gave them an environment free from distraction."

View all my reviews

Thursday, February 21, 2019

Ethical vs Policy Crisis

Penny Arcade comic showing a father explaining why he wouldn't let his daughter play a specific game.

This past Christmas I read a lot of posts from my friends about their kid's love of Harry Potter and their Harry Potter themed Christmas gifts. It is pretty awesome that they were able to have this shared interest. So when I read this past Penny Arcade comic, https://www.penny-arcade.com/comic/2018/04/30/hogwash, I was shocked and angered. This hits close to home: My friends might be experiencing this extortion. If the comic doesn't provide enough information (it didn't for me) then read (or skim) https://www.eurogamer.net/articles/2018-04-27-harry-potter-hogwarts-mystery-is-ruined-by-its-in-game-payments.
Summary: There is a scene in the game where the player (your child) is getting choked by a vine. They can either pay real money in order to stop it or wait for their energy to recharge (many minutes of watching their avatar get choked). And there are many other things like that.
This comic strip is so spot on; panel 2, especially so. I've read several articles in the last few months calling for Computer Science to include ethics in more classes instead of the traditional capstone course on ethics. In the Jan 2019 issue of CACM, Moshe Vardi pointed out that more ethics in classes will be nice but that it won't change anything. The only thing that will force these companies to change is public policy -- regulation that bans these practices that target children. (Sorry, I have to say it for the sake of completeness.) If this stuff* matters to you then you need to write to your state representatives.

* stuff being any unethical practice being carried out via a computing device.