unpythonic

> Then, checking on Google Scholar, Heneberg saw that many of the remaining papers actually had been referenced by other works indexed in the Web of Science, but had been missed because of data-entry errors or typos in the papers

I wonder if you could look at the number of citations to non-existent papers to find these typos. If you collected such a set, you could do a loose search against the list of published papers, and see how many are a close match. For instance, a typo in an author's name or the paper's title could be ignored while matching the journal, date and page could give the auditors a list of best guesses for this missed citations.

When I worked for a very large networking company, we wanted to bring in a small company's only product which would have been central to the day-to-day running of engineering. Because they were so small with so little track record, we wanted to make sure that we could get their source code should they ever go out of business.

I can't think of a good reason to require code inspection prior to purchase. Testing, measuring, and generally trying to break the code during evaluation seems fair game though.

Since brevity is the soul of wit / And tediousness the limbs and outward flourishes, I will be brief... Wit should fit on a Hollerith card.

I got mine from Audible at the link below. If you do use it, please SKIP THE INTRODUCTION. If you haven't read or listened to the book before, it gives away some major plot points as part of the author's update.

https://www.audible.com/pd/Bios-Memoirs/Zen-and-the-Art-of-M...

I used to commute in silence or listening to the radio for my daily Silicon Valley drive (237 Milpitas to Mountain View), and by the time I got to work, I'd be angry, frustrated, and cognitively spent.

Listening to audio books has allowed me to relax, enjoy the reading, and get to work excited about the day.

I treat the time as a chance to "read" those books which I wouldn't normally spend either my work hours nor my free time hours on. It's a chance to get informed on topics that are only slightly related to work, but expand your mind in ways that will make you a better thinker, and thus a better programmer.

The books I've found particularly good on audio are:

* Zen and the Art of Motorcycle Maintenance

* Thinking, Fast and Slow

* How Not to be Wrong

* Ready Player One

* Neuromancer

I've been a programmer for 30 years, and I could reasonably be considered to be a senior dev.

Yes, I'm very happy with my job. I work at a company which cares deeply about solving hard problems well, and that care translates into good working conditions, great work/life balance, support from management for engineering concerns, and a very nice benefits package. There is also a focus on having separate promotion tracks for managers vs. more technically inclined people.

There have been jobs where I have either tired of the novelty of the problems, changes in management, changes in company policy, etc., but at that point I find a new job in a better company and continue to find happiness.

If you're not happy where you are, and you are considered a senior dev, then take responsibility for yourself and find a position that you enjoy. If you're locked into a company because of golden handcuffs, lack of local resources, or family obligations, then find activities outside of work that provide what you're missing.

The details for the infection can be found at Malwarebytes, the discoverer of this issue:

https://blog.malwarebytes.com/threat-analysis/2017/01/new-ma...

This article has the signature of the infection as well as listing the servers with which it communicates.

From the article:

One customer had nine years left on their mortgage. Wells Fargo extended that to forty years, giving Wells Fargo an extra $40,000 in interest.

Another customer had fourteen years left on their mortgage, it was extended to forty years, giving Wells Fargo an extra $85,000 in interest.

If you're expecting to retire with your house paid off, the additional 31 or 26 years of payments could ruin your life.

For those of you living in the San Francisco Bay Area, and especially for those living in San Jose, you can interact with Pepper at Valley Fair Mall -- Pepper being the AI-infused robot which was one of Softbank's previous acquisitions.

https://www.westfield.com/valleyfair/services/all-services/p...

Generally only small children play with it, and it has the affect of a children's companion.

This study seems to show that sugar-sweetened beverages are positively correlated with insulin resistance while diet soda does not have that same association:

http://jn.nutrition.org/content/146/12/2544.short

Sugar-Sweetened Beverage but Not Diet Soda Consumption Is Positively Associated with Progression of Insulin Resistance and Prediabetes

From the footnotes on the link given:

- Supported by the NIH/National Heart, Lung, and Blood Institute’s Framingham Heart Study (contract N01-HC-25195), the Boston University School of Medicine, and the USDA (USDA agreement 58-1950-0-014

- Author disclosures: J Ma, PF Jacques, JB Meigs, CS Fox, GT Rogers, CE Smith, A Hruby, E Saltzman, and NM McKeown, no conflicts of interest

Are you going to continue family life the automated way? Perhaps start a family using Jenkins: an enjoyable build process, lots of tests along the way, and release to production once they're out of college.

The contingency table shows these very clearly, but I believe the question is about the future popularity table.

The future probability table shows that Swift is to the left of (smaller future probability) of Objective C. The coloring of the chart shows a much darker square for Swift -> Objective C than for Objective C -> Swift.

It seems surprising given your contingency table that your analysis would show that Objective C is going to be the more popular of the two.

It's in the Constitution: "No Person except a natural born Citizen, or a Citizen of the United States, at the time of the Adoption of this Constitution, shall be eligible to the Office of President". - Article II, Section 1, Paragraph 5

As you can see, this covers the corner case you've identified.

Interestingly, the term citizen wasn't defined until the 14th amendment: "All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the State wherein they reside"

Oh, that's great to know. That coupled with filling out the size to an uninteresting length with nulls (or another delimiter) covers my concerns. For example:

    $ echo "my secret" | dd bs=512 conv=sync | docker secret create my_secret_data -

This looks amazing. Solving secret distribution across containers will be very useful. Being able to see via `docker secret` exactly which services are using which secrets is an unexpected treat.

I'm a little worried about two aspects of what has been shown. From the article it shows:

    $ docker exec $(docker ps --filter name=redis -q) ls -l /run/secrets
    total 4
    -r--r--r--    1 root     root            17 Dec 13 22:48 my_secret_data

From this we can tell exactly how long the secret is. If the secret service didn't do it for us, I'd like for the secrets to be null-padded to a uniform 2-4K of bytes.

I'm also a bit worried that the default protection on the file has it set to world-readable. Since it appears that secret distribution is independent of the container setup itself, there doesn't appear to be any way of setting ownership and permissions on this file. That is, if one were able to chmod/chown the file in the Dockerfile, running a `docker service update --secret-rm` and `docker service update --secret-add` would reset such 'fixes'.

A great start, and I can't wait to start using it.

Given that everything must go through shipping & handling which is typically measured in days, what is the benefit to ordering immediately? Surely these services could batch your requests through the day and push a confirmation request to the buyer(s).

The risk of unintentional purchases seems much too high, and one doesn't lose much convenience with a quick confirmation.

Love the /e for executing the substitution

    $ echo abc9def | perl -pe 's/(\d+)/$1+1/e'
    abc10def

This has been my go-to page for movie information for the longest time. Yet again, Google is training us not to trust that any of their services will be available -- this one seemed to be shutdown without any notice whatsoever.

I know it's a free service, and that Google is under no obligation to me. For these reasons, I've never taken them up on their "free" storage, G+, or any other up and coming services.

This was a very useful service, and I'll miss it a lot.

This is a rambling article with a conclusion which isn't supported by any of the rambling, that conclusion being that "fortune-telling is simply an exhibition of one of many possibilities, rather than the absolute truth. It is, therefore, never really wrong".

It includes a very unusual view of Heisenberg's uncertainty principle where the author quotes without attribution "Everything in the world looks coincidental by any current observation method, since any law or principle is expressed only probabilistically. No one can say whether a thing has absolute inevitability". The only reference I could find to this via Google was http://large.stanford.edu/history/kaist/web/clubs/times/feat..., which also quotes without attribution.

I don't understand why such an article was submitted here.

The failure of the Mars Climate Orbiter usually stars in hallway discussions on types or notation. This article shows a long chain of failures far more subtle than the punchline to which it's relegated. Design failures in the beginning led to untracked course translation during what was supposed to be rotation-only maneuvers. The infamous units of thrust issue between JPL (newtons) and Lockheed (pounds force) was certainly an issue, but from the article it doesn't seem to be the primary cause of failure. And finally management defaulting to an everything-is-ok attitude and ignoring the nervous input of the navigators meant that when evidence was building that something was wrong, it was ignored.

The article quotes the paper, which says “… learning things that are likely to improve your performance at school (e.g., reading; developing knowledge and skills in math, science, or the arts), on the job (e.g., updating your knowledge of content and standards in your profession), or in activities that are other-wise enjoyable.”

Using an app to learn a new language, extend your vocabulary, or learning new arithmetic tricks would seem to fall into this category. If the Elevate app actually does any of these, then I'd call it "learning" instead of "brain training".