< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #8 - April 28, 2019

Here are the top threads of the week, happy reading!

Top comment by gottebp

Breville coffee grinders are impossible to get internal parts for. I designed a 3D printed upgrade for the main wear-part in their BCG800XL and BCG600SIL Grinders.

The storefront is through ShapeWays[1] and I use iFixit[2],[3] to drive the traffic. It passively makes enough to cover my own coffee needs forever. I spend about 20 minutes per month fielding questions. This all happened because my grinder failed and I could not get parts.

[1] https://www.shapeways.com/product/NASLAGCCP/breville-coffee-...

[2] https://www.ifixit.com/Guide/BCG800XL+Grinder+Jamming+due+to...

[3] https://www.ifixit.com/Guide/BCG600SIL+Dose+Control+Pro+Coff...

Top comment by lugg

If you got an email you should:

- Change your password on https://hub.docker.com

- Check https://github.com/settings/security

- Reconnect oauth for Automated Builds

- Roll over effected passwords and API keys stored in private repos / containers

Quick take:

- Password hashes

- Github tokens

- Bitbucket tokens

- Your Automated Builds might need new tokens

Checking my github logs - It looks like they've known about this for at least a full 24 hours. Most people aren't going to have this looked at until Monday which kind of sucks. Hopefully there is more of a postmortem coming.

Is anyone from github able to comment on this as well?

There doesn't seem to be a way for us to tell if a repo was read by these keys over that time period.

Top comment by AWebOfBrown

A quote about salary, that I bookmarked as I could see myself making the same mistake:

"Salaries never stay secrets forever. Hiding them only delays the inevitable. Last year we were having a discussion at lunch. Coworker was building a new house, and when it came to the numbers it was let loose that it was going to cost about $700K. This didn't seem like much, except to a young guy that joined the previous year and had done nothing but kick ass and take names..." (edited for brevity).

"...The conversation ended up in numbers. Coworker building the house pulled about $140K base (median for a programmer was probably $125K), and his bonus nearly matched the new guy's salary, which was an insulting $60K -- and got cut out of the bonus and raise in January for not being there a full year, only 11 months.

Turns out he was a doormat in negotiating, though his salary history was cringeworthy. It pained everyone to hear it, considering how nice of a guy he was. In all honestly, $60K was a big step up for him. Worst of all, this wasn't a cheap market (Boston). The guy probably shortchanged himself well over a half-million dollars in the past decade. This was someone who voluntarily put in long hours and went out of his way to teach others, and did everything he could to help other departments like operations and other teams. On top, he was beyond frugal. Supposedly he saved something around 40% of his take home pay, despite living alone in Boston. He grew up in a trailer park.

He spent the next day in non-stop meetings with HR, his manager and the CTO. That Friday he simply handed in his badge without a word, walked out and never came back.

Until 3 months later. As a consultant. At $175/hour."

https://news.ycombinator.com/item?id=2439478

Top comment by srirangr

1. Tell them what to do but do not tell them how to do it. (Just give a few pointers otherwise they'll be lost.)

2. Give them a playground to fail - Offload any non-business critical tasks and let them make mistakes. No one I know ever learnt programming without making any mistakes. Immediately tell them about best practices and how to avoid such mistakes in future.

3. Show them the impact of their work - There's nothing more motivating than seeing the impact of one's work.

4. Build curiosity - Answer as many questions as you can answer. Admit when you don't know any answers and start looking it up on the web right in front of them. People pick habits by looking at their superiors.

If it's absolute beginning to programming, this video is a great way to show how difficult it is to teach a machine to do something and how clear instructions can help get things done: https://www.youtube.com/watch?v=cDA3_5982h8

Top comment by tomasdpinho

As a DevOps Engineer working for a ML-based company and have had worked for others in the past, these are my quick suggestions for production readiness.

DOs:

If you are doing any kind of soft-realtime (i.e. not batch processing) inference, by exposing a model on a request-response lifecycle, use Tensorflow Serving for concurrency reasons.

Version your models and track their training. Use something like MLFlow for that. Divise a versioning system that makes sense for your organization.

If you are using Kubernetes in Production, mount NFS in your containers to serve models. Do not download anything (from S3, for instance) on container start up time unless your models are small (<1Gb).

If you have to write some sort of heavy preprocessing or postprocessing steps, eventually port them to a more efficient language than Python. Say Go, Rust, etc.

DO NOTs:

Do NOT make your ML engineers/researchers write anything above the model stack. Don't make them write queue management logic, webservers, etc. That's not their skillset, they will write poorer and less performant code. Bring in a Backend Engineer EARLY.

Do NOT mix and match if you are working on an asynchronous model, i.e. don't have a callback-based API and then have a mix of queues and synchronous HTTP calls. Use queues EVERYWHERE.

DO NOT start new projects in Python 2.7. From past experiences, some ML engineers/researchers are quite attached to the older versions of Python. These are ending support in 2020 and it makes no sense to start a project using them now.

Top comment by barry-cotter

I doubt there’s been too much on software interviewing specifically but interviewing/candidate selection for jobs is a large part of personnel psychology. A recent meta-analysis of what they know is below. Basically general mental ability (g, IQ) is the single best predictor, work sample tests work well, structured interviews can increase the performance of IQ tests or work samples and unstructured interviews are a trash fire.

> The Validity and Utility of Selection Methods in Personnel Psychology: Practical and Theoretical Implications of 100 Years

> This article summarizes the practical and theoretical implications of 85 years of research in personnel selection. On the basis of meta-analytic findings, this article presents the validity of 19 selection procedures for predicting job performance and training performance and the validity of paired combinations of general mental ability (GMA) and the 18 other selection procedures. Overall, the 3 combinations with the highest multivariate validity and utility for job performance were GMA plus a work sample test (mean validity of .63), GMA plus an integrity test (mean validity of .65), and GMA plus a structured interview (mean validity of .63). A further advantage of the latter 2 combinations is that they can be used for both entry level selection and selection of experienced employees. The practical utility implications of these summary findings are substantial. The implications of these research findings for the development of theories of job performance are discussed.

https://www.semanticscholar.org/paper/The-Validity-and-Utili...

Top comment by brundolf

Employee of Cycorp here. Aside from the current ML hype-train (and the complementary unfashionability of symbolic AI), I think the reason symbolic AI doesn't get as much attention is that it's much more "manual" in a lot of ways. You get more intelligent results, but that's because more conscious human thought went into building the system. As opposed to ML, where you can pretty much just throw data at it (and today's internet companies have a lot of data). Scaling such a system is obviously a major challenge. Currently we support loading "flat data" from DBs into Cyc - the general concepts are hand-crafted and then specific instances are drawn from large databases - and we hope that one day our natural language efforts will enable Cyc to assimilate new, more multifaceted information from the web on its own, but that's still a ways off.

I (and my company) believe in a hybrid approach; it will never be a good idea to use symbolic AI for getting structured data from speech audio or raw images, for example. But once you have those sentences, or those lists of objects, symbolic AI can do a better job of reasoning about them. Pairing ML and symbolics, they can cover each other's weaknesses.

Top comment by dusted

Earning around 75000 usd/year as a software dev in Denmark. Very relaxed work, fun days, flexible time, no education, paid house and car in cash, never loaned, still got more money into my account each month than I know what to do with, it just accumulates, live a very comfortable life, never looks at prices when shopping, never in need of anything. Profoundly confused why one would focus on obtaining such excessive salary.

Top comment by gwbas1c

When I worked for Intel, we all went through training on how to run effective meetings.

Why? In a distributed team, meetings can become a severe time sink. A lot of people hold meetings to feel busy and important, and even less people put in effort to keep the conversation focused so that the meeting ends on time.

Some basic things are:

- Determine an agenda in advance. The agenda must be part of the meeting invite. An agenda is more than "Talk about XXX." You should have a list of 3-6 topics that will be discussed in the meeting.

- Make sure that everyone on the invite list needs to be there. Explain why you're inviting people in the meeting invite.

- During the meeting, make sure that, as time progresses, the topics on the agenda are discussed. If one topic is discussed too long, there's different techniques for moving to another topic. (Binning it, declaring it a rathole, ect.)

- Decline poorly planned meetings.

And, I shouldn't need to say this, but meetings begin on time and end on time. Don't make everyone wait 45 minutes to start what's supposed to be a 30 minute meeting, but then it really drags out to 90 minutes.

Furthermore, have a 0-tolerance policy for latecomers and people who always need 15 minutes to figure out the teleconference software. Hold your interviews in the teleconference software you use with your team as a way to filter out the idiots.

Top comment by whatthesmack

It seems that the issue may be specific to us-east-1...

https://console.aws.amazon.com/console/home?region=us-east-1

...doesn’t work, but:

https://us-west-2.console.aws.amazon.com/console/home?region...

...works.