The Biggest Concerns About GMO Food Aren't Really About GMOs

Everyone from Chipotle to the Food Babe rails against genetically modified ingredients, and laws to label GMO foods are making progress in some states. But the laser focus on GMOs is misguided, because most of the concerns people raise about them aren’t really about GMOs.

“GMO” is the buzzword for genetically modified crops where the plant’s DNA has been changed in the lab, typically by inserting a gene from another species. Technically there are other types of genetically modified organisms (living things), but no GMO animals are used in our food, and GMO bacteria are widespread but not controversial.

Source: The Biggest Concerns About GMO Food Aren't Really About GMOs

This whole article is a must read for anyone interested in the current state of how the modern food system works. It's pretty incredible in actually looking in depth at a slew of mechanisms used to hybridize our food, and which the GMO label actually only applies to a very narrow slice of some of the most well controlled using bacterial gene transfer. A mechanism that was recently discovered to have happened naturally, thousands of years ago, with the Sweet Potato.

Also, incredibly, the comments on that article are incredibly thoughtful and nuanced. It's one of the few internet conversations that I've seen recently where people were legitimately curious and thought provoking.

 

Clean Up Your Mess - A Guide to Visual Design for Everyone

If you're like most people, you feel like a baby when it comes to visual design. You sometimes have a vague sense of what you want, but can't articulate it or make it come about. All you can do is point and cry. This guide will help you communicate with conscious skill. It will show you how to create designs that are easy to understand and attractive.Beyond giving you practical tools, I hope this guide inspires you. One of my favorite quotes is, "I open my eyes and I see paradise." What a great gift vision is! What an incredible way to connect to the world around us and to each other. My hope is that this guide will allow you to communicate with more creativity and more control – and that you'll want to learn more.

 

 

 

 

 

 

 

Source: Clean Up Your Mess - A Guide to Visual Design for Everyone

A great design primer. If you learn nothing else from it don't ever center justify text will immediately make everything you do better. Center justification is for people that can't commit. Go hard left or hard right justification and take a stand.

This Is How Fast America Changes Its Mind

As the Supreme Court considers extending same-sex marriage rights to all Americans, we look at the patterns of social change that have transformed the nation.

Source: This Is How Fast America Changes Its Mind | Bloomberg Business - Business, Financial & Economic News, Stock Quotes

Really interesting visualization and look at how social issues hit a tipping point far faster than one might expect, and then the federal government just steps in and unifies things. Love looking at data sets like this.

Ebola behind a paywall

MONROVIA, Liberia — The conventional wisdom among public health authorities is that the Ebola virus, which killed at least 10,000 people in Liberia, Sierra Leone and Guinea, was a new phenomenon, not seen in West Africa before 2013. (The one exception was an anomalous case in Ivory Coast in 1994, when a Swiss primatologist was infected after performing an autopsy on a chimpanzee.)

The conventional wisdom is wrong. We were stunned recently when we stumbled across an article by European researchers in Annals of Virology: “The results seem to indicate that Liberia has to be included in the Ebola virus endemic zone.” In the future, the authors asserted, “medical personnel in Liberian health centers should be aware of the possibility that they may come across active cases and thus be prepared to avoid nosocomial epidemics,” referring to hospital-acquired infection.

What triggered our dismay was not the words, but when they were written: The paper was published in 1982.

via Yes, We Were Warned About Ebola - NYTimes.com.

The information existed that Ebola existed in Liberia. However, that information was trapped behind a research journal paywall, so didn't end up in the hands of the people that really could have used it. A contributing factor to why this Ebola outbreak got so out of control.

Choose Boring Technology

But of course, the baggage exists. We call the baggage "operations" and to a lesser extent "cognitive overhead." You have to monitor the thing. You have to figure out unit tests. You need to know the first thing about it to hack on it. You need an init script. I could go on for days here, and all of this adds up fast.

...

The problem with "best tool for the job" thinking is that it takes a myopic view of the words "best" and "job." Your job is keeping the company in business, god damn it. And the "best" tool is the one that occupies the "least worst" position for as many of your problems as possible.It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this.

via Dan McKinley :: Choose Boring Technology.

I've had way too many conversations recently that had some variation of "people should just get over it and learn new things". New has a lot of cost. Even if it's good, new brings load. If you exceed the digestion rate of new technology on people, they hit a wall, give up, and go home mad.

OpenStack Emacs Tools

Over the past few weeks I've been tweaking my emacs configs, and writing some new modes to help with OpenStack development. Here is a non comprehensive list of some of the emacs integration I'm finding useful in developing for OpenStack (especially things that have come up in conversation). URLs provided, though I won't walk through all configuration in depth.

tramp

Tramp is a built in facility in emacs that lets you open files on remote machines via ssh (and other protocols). This means your emacs runs locally, with all the latency gains that has, as configured as you would like, but editing can be done across multiple systems. A remote file url looks like /servername:/file/path. All the normal file completion that you expect works after that point.

I tend to do code that doesn't need a full stack run locally on my laptop or desktop, but full stack code happens on my NUC devstack box, and tramp lets me do that from an single emacs instance.

More info about tramp at emacswiki.

fly-hack

Emacs has an in-buffer syntax checker called flymake. There are various tutorials out there for integrating pyflakes or flake8 into that. However in OpenStack we have hacking, which extends flake8 with new rules. Also, every project turns on custom ignores. Also, many projects extend flake8 further with custom rules for that repo.

screenshot_151

fly-hack uses the flake8 in the .tox/pep8 venv for each project, and uses the tox.ini config for each project, so when in Nova, nova rules will be enforced, when in Cinder, cinder rules will be enforced. Mousing over the error will pop up what it is (you can see the H306 in that screenshot). It has a fallback mode when using it over tramp that's a reasonably sane flake8 least common denominator for OpenStack projects.

More info at fly-hack github page - https://github.com/sdague/fly-hack

stacktest

Our testr / subunit / testtools testing toolchain gets a bit heavy handed when trying to iterate on test development. testr discovery takes 20 - 30s on the Nova source tree, even if you are trying to only run 1 test. I became inspired at the Ops Summit in Philly to see if I could do better. And stacktest.el was born.

screenshot_153

It's mostly a port from nosemacs which allows you to run tests from an emacs buffer, however it does so using tox, subunit, or testtools, depending on whether you want to run a top level target, test a file, test an individual test function, and/or use pdb. It works over tramp, it works with pdb, and it uses the subunit-trace tooling if available.

I've now bound F12 to stacktest-one, which is a super fast way to both iterate on test development.

More info at the stacktest github page - https://github.com/sdague/stacktest

pycscope

OpenStack is a lot of code, and uses a ton of libraries. git grep works ok in a single repo, but the moment some piece of code ends up calling into an oslo library, that breaks down.

Peter Portante, OpenStack Swift contributor, maintains a pythonized version of cscope. It parses the AST of all the files to build a quite rich symbol cscope database. This lets you search for definitions (searching down), calling points (searching up), and references (searching sideways). Which very quickly lets you dive through a code path and figure out where you end up.

screenshot_155

The only draw back is the AST parse is consuming on something as large as the Nova tree, especially if you index all the .tox directories, which I do to let myself get all the way back through the library stacks that we include.

You can learn more about pycscope at it's github page - https://github.com/portante/pycscope

flyspell-prog-mode

Emacs includes a spell checker called flyspell. Very useful for text files. What I only learned last year is that there is also a flyspell-prog-mode, which is like flyspell, but only acts on comments and strings that are semantically parsed by Emacs. This helps avoid a spelling mistake when writing inline documentation.

screenshot_156

More information at Emacs wiki.

lambda-mode

This is totally gratuitous, but fun. There is a small mode that does a display adjustment of the word 'lambda' to an actual 'λ'. It's a display adjustment only, this is still 6 characters in the buffer. But it makes the lambda expressions pop out a bit more.

screenshot_157

More information at Emacs wiki.

The important thing about having an extensible editor is actually extending it to fit your workflow. If you are an emacs user, hopefully this will give you some fun things to dive into. If you use something else, hopefully this will inspire you to go looking into your toolchain for similar optimizations.

Keeping track of work / life balance

Working from home is great. No commute. Really good coffee 50ft away. Being able to get started as soon as I wake up. Being able to break for exercise / food / etc when it fits in my natural flow, instead of having to work around an office / commute schedule.

There are some drawbacks. One of which is there is no real signal on when the day is done. Not realizing the building has emptied out and you shouldn't be there any more either. I had a few weeks early in the new year where I was completely burnt out and grumpy by the time I got to Thursday. Doing some quick mental math, I realized I had put in far too many hours those weeks.

I have a pretty solid work from home routine. I work in my home office (and that's almost the only time I'm in there). I have a fast desktop computer that I do all my work from when I'm home. Enough so that I've written automation around the screensaver events to do things like mark me away on IRC. This seemed like a natural way to keep track of how much I was actually working at my computer through recording all the lock / unlock events.

screenshot_216

The latest version of this program records these lock events week by week. It can then add them together and give me a view on how long I've worked both today, and this week. A Linux desktop notification is sent every time the screensaver is unlocked, as well as every time it hits a round number. It's just enough of a signal to realize it's time to stop for the day / week.

I've been doing this for a month now. The results are interesting. First, I learned out much I was actually working. It was far more than I had realized. So I consciously started capping days and weeks when I got to a number I felt was fair. This often means that Friday is a pretty light day, and includes a long family lunch outing. It also means I never miss a chance for a family walk in the middle of the day, because I have time for it, I even have numbers to prove it. (Note: I'm mostly proving it to myself so I don't feel guilty when I put down the computer, as I work in a great organization where no one else cares about this as a metric.)

It's also had an interesting impact on free time hacking. I now still have enough energy in my tank at the end of the week to still be able to do interesting things with computers that aren't strictly work. Saturday mornings before the girls wake up has become tech exploration time again. This has included relearning elisp, and actually writing some emacs extensions recently (fly-hack, stacktest). I also made progress on my home weather station code for the first time in a year.

It's amazing what happens when you measure a thing, not for anyone else, but for yourself.

Various rambling thoughts from my personal corner of the internet