devnull255

Wow. Build a beautiful, long piano and they will come!

This is so awesome. It almost made me cry. I think it's a brilliant way to introduce a complex technology because we have all grown up to absorb lessons through stories, especially stories about cute animals. And you know what? we remember those stories and the lessons we glean from this. I'm also glad I can swap the image I have of Franz Kafka's Gregor Samsa bug with cute otters.

Living eventually leads to death I've heard.

Wow! How did I miss this structure in Python in all the years I've worked with Python? Oh. I remember. Because it took so long for me move from Python 2 to Python 3. So I'm catching up.

Anyway, I enjoyed this article mostly because it jumped right into what it was for. It often takes articles just like this one to alert folks like me to one of the more interesting tools the language has to offer. I happen to have a number of projects I have to make changes to that might benefit from this structure. So kudos!

I love this story because the story has a an unwritten and deeper title "Do what you love and love what you do". True, while the unwritten title may not have grabbed most of those here who really appreciated it (myself included), it underlies what arguably really motivates a lot of teens to work any job, which is working a job doing what they like.

I was "tricked" or "crimped" into my first job the day before my 16th birthday. I accompanied my dad on a shopping trip, and he asked the manager there if he was hiring, gesturing to me. I didn't have a chance to express my own point of view in the course of this conversation. And by the time we left the store, I was supposed to show up the next day to be hired.

I wasn't thrilled to work there, but the first paycheck I received motivated me to continue working. It funded my evenings out and my sci-fi and comic book collecting, and let me save for my first car, a '71 red Buick Skylark with powerful V8.

But I would have liked it better if the story of my first job was more like this story.

While completely unplugging from social or mainstream media for a while is one strategy to keep outrage levels at bay, you can also choose a strategy of quality over quantity for consuming information about the world.

This is also a strategy that involves depth over breadth of information sources. Choose longer and more thoughtful articles in respected journals instead of headline news bursts. Read books that provide deeper analysis and context of topics given insufficient context in headline news.

Watch shows like Last Week Tonight with John Oliver or The Daily Show that make you laugh while often giving you more thoughtful reporting and analyses of current events than traditional news sources. I might have included Real Time with Bill Maher, but lately I've found that show dials up my outrage against the host. In any event, you should tailor this strategy to your own outrage triggers.

Finally, while excess outrage can be harmful to your mental health, it also provides input about what is important to you. Or at least, what you think is important to you. For this reason, it's probably also useful to take the opportunity to be mindful of what it is that is triggering the outrage and determine if there is a deeper issue provoking the outrage. Doing this might actually help you regulate your own emotions while processing difficult information.

If you dig a little deeper you might find your brain does make that kind of connection subconsciously.

This article gives a nice introduction into the work of cognitive linguists George Lakoff and Mark Johnson. https://theconversation.com/how-did-white-become-a-metaphor-.... The language constructs we use embed positive and negative associations with the words used to describe black or white things, low or high concepts.

But I have to admit my bewilderment with the default branch name change too. I've seen older uses of the word master to mean original source of truth or master of students -- or padawan.

I believe it's better to live in a time where we think more seriously about the words we choose to use than in one we don't. Language is fluid and always changing anyway.

I've found the importance of remembering a book you've read depends on why you're reading the book in the first place. If you're reading to entertain, remembering what you've read isn't nearly as important as the experience you get reading it. It's why I've reread so many of the science fiction and fantasy books I love. Reading a book again, especially long after the original reading of it, re-ignites the pleasure of the experience of the first reading.

The third and fourth levels of reading often require the reader to do exactly what you describe. I've actually started using paper index cards to do this, creating physically cataloged notes, which through the muscle memory of writing, help to embed the most important concepts and idea in my brain.

I personally read a lot of books that inform or advance important ideas casually first. Then I go back and re-read sections, taking notes more carefully to properly ingest the critical topics into memory.

It inspired perhaps the greatest modern work of all time! https://en.wikipedia.org/wiki/Kilroy_Was_Here_(album)

Domo arigato!

As someone tasked with supporting build and release automation in a large company using Gradle, it's never been enough to learn just enough Gradle and Groovy to build any project, because I learned in a relatively short time that there's no end to all the ways something won't build because of what I didn't know about Gradle or Groovy for a particular build scenario. I also didn't expect to see how a gradle process might behave differently in a Jenkins pipeline job from how it behaves when you run a build interactively at the command line. And least but not last, who would have thought how much of a headache it might be figuring out why an IDE with a Gradle plugin built a project just fine while building with Gradle on the command line or in Jenkins failed.

Some of the issues I eventually figured out had to do with missing or incomplete documentation explaining some of the caveats or gotchas of Gradle constructs that one might assume should work the same way. For example, the use of old-style vs new-style code for plugins (buildscript/apply plugin vs. plugin DSL) is not always interchangeable. The new-style works at the top-level of multiproject builds but one must use the old apply plugin form in subprojects.

We've had to use Gradle to build non-java projects as well, which need to use Exec and Copy tasks to build and stage build artifacts. However, the Copy tasks, which are usually dependent on the Exec build tasks, don't always execute after the tasks they are dependent on have completed. Or rather, a Gradle project built on the command line will successfully respect those dependencies while a Jenkins job will output NO-SOURCE in the task execution step.

The problem with Gradle is that it is not as simple as Make, which I had to use in a prior position. However, successful use of Gradle does require significant more investment in learning more than you first think you might need to know about Gradle in a tutorial. It also requires significant investment in learning about Groovy, which will help illuminate how the Gradle DSL works.

I've had two colonoscopies 5 years apart because in the first procedure they found and removed polyps, which put me on the side 5-year plan (every 5 years). In the last procedure polyps were also found and removed. Since at least one of the polyps removed in both procedures were benign but possibly capable of becoming malignant, the FIT test by itself is probably not sufficient for me as the only cancer screening test.

It looks a lot like the author of this article formed an opinion about Python based on a frustrating experience with a poorly-documented library, a fondness for other languages and maybe some misconceptions or lack of knowledge, not just about the Python programming language, but about programming in general.

First, I wasn't quite sure what was going on with the discussion about OOP. Smalltalk has classes just like Python does. True, the former allows multiple inheritance, which is not at all required in whatever kind of class you want to design. In fact, like a lot of other OOP or OOP-like languages, you can utilize other schemes to extend the behavior of classes (composite classes, decorators, etc).

But the discussion of libraries (there's a library for everything in Python!) and the particular rant on the poorly documented library gave me ... more pause. Libraries and lots of useful libraries is one of things that makes Python a "batteries included" language choice.

After finishing the article, I realized that the article was all about how frustrating it was trying to use it that library was. And how poor the documentation was. But truthfully, these gripes can be found in any programming language implementation of a ... thing.

As referenced in the comment with the Foucault quote, the modern school and prison are both structures designed in a way that makes it easier for their authorities (wardens, guards, principals and teachers) to contain and control their captive populations (prisoners and students).

In his book "Discipline and Punish", Foucault argues that in the establishment of the modern prison, the mission of imprisonment shifted from punishing those who were imprisoned to reforming and disciplining them to become better citizens. The same organizing principles of command and control developed for "modern" prisons were applied to the "modern" school as well. I thought the game eerily demonstrated how similar prisons and schools look to one another. Both kinds of buildings are designed to limit access to the building and also egress.

As it was in 2007, it is only "mostly dead". I am reminded of this every time I start work on my Dell machine running Windows 10, which is also maybe mostly dead, but not dead enough? Microsoft seems to still occupy living spaces in the enterprise desktop marketplace. So what exactly is mean by death here? Innovation? Dominance? Marketshare?

And death where? The application space? The cloud space? Most comments I've seen here suggest Microsoft still lingers in these domains. Its tentacles still manage to reach Cthulhu-like into spaces that weren't expected.

Has it really though? Or is it more the case that most modern humans are being flooded with unprecedented loads of data about the world and have not been sufficiently educated in systems thinking to recognize the world as interlocking systems?

The opening bit in the article about the shipping container captain receiving electronic orders to slow the ship's speed doesn't necessarily show our willingness to accept orders without question from an algorithm. But it does reveal a lot about how the author may not quite understand how shipping schedules work, or grasp how things like overcrowded shipping ports, available dock personnel and functioning equipment may result in congestion that delays or even prevents unloading product from the ship.

It seems more likely that because information technology has become so ubiquitous in our lives, modern humans have become more detached from the world it, unable to recognize the real-world objects and processes it represents.

I definitely miss having the option to work from the office.

I miss the commute time ( never more than an hour and a half on the busiest of commutes ) and the transition from home to work and work to home again.

I don't think I cared for doing either full time; office or working from home. So I liked being able to mix it up. The variation of it was refreshing.

I liked experiencing the increased likelihood of encountering unexpected events and people. The greater randomness of experience.

vi/vim is my editor of choice because the shell (ksh or bash) is my primary IDE.

The last 20 years or so has required me to develop mostly scripting (ksh, sh or bash) that is executed by some sort of automation. The shell is where I spend most of my time executing commands that need to be scripted, inspecting various system resources and troubleshooting. The vim editor is readily available to use in places where external tools outside of a terminal emulator may not be readily available or the startup time required to configure those tools may be better spent on configuration tweaks in the shell.

I've also found especially when working with build automation in Jenkins or deployment automation with uDeploy, that a GUI-based client IDE somewhat obscures things I need to see in the environment I am building in. IDEs like Eclipse and IntelliJ IDEA, while providing plugins for Gradle or Maven, may have configurations that are not compatible or differ in some fundamental way from those of the server build environment.

In Linux, processes scheduled in cron, systemd or other schedulers don't require and may sometimes have issues with the customizations in login scripts for interactive sessions. Login scripts may expect input from the user keyboard, or may depend on environment variables that exist when a login script is executed, but not when nonlogin scripts execute.

"Alexa, do not disturb."

I use this feature regularly to prevent drop-ins when I don't want them.

Well, one particular grievance among them, that a person passing off a counterfeit 20-dollar bill doesn't deserve death at the hands of police, probably is legitimate. Choosing to remediate that injustice is not capitulation to the mob, but fulfillment of the promise of equal protection under the law that the democratic process was supposed to protect.

At the company I currently work for, Jira has become yet another opportunity to engage in metrics abuse. Probably because Jira makes it easy to create reports and dashboards that are more useful for managers than for delivering software.

The company, which has "committed" itself to "embracing agile", has implemented some new employee performance policies which clearly demonstrate those decision makers don't know wtf agile is. One such policy is tying performance to "individual velocity" or story points per sprint per individual completed. Some managers, especially my current manager, care more about individual velocity than what velocity is supposed to be used for.

Consequently, developers can be raked over the coals if their individual velocity dips below a pre-determined number. When my manager confronted me with my lackluster individual velocity over the last few sprints (shown by a Jira report), I first tried to convince him that team velocity mattered more and that it was supposed to be a metric used for planning work for a sprint, not as a forecast metric. I tried to get him to see that velocity for everyone would improve when we got better at prioritizing and creating stories that allowed us to deliver value each sprint. It would also help too if we could function better as a team. But he wouldn't have any of that. I just had to improve my personal velocity.

So I learned how to use Jira better. I created pointed stories in the backlog I knew I could finish in a sprint and meet my forecasted velocity. The next time my manager ran his Jira report, he remarked on the improvement. The amount of work I actually did didn't change, but my individual velocity did.

While I agree with the premise of the OP about Jira. I would go even further than just Jira and say that today, proficiency and mastery of any tool used in the software development lifecycle seems to be more important than knowing how to do software development right.

This is a fantastic article and reading list. I'm disappointed at how so much of the discussion around the most recent rioting has devolved to being pro-protest vs anti-rioting. The riots, like the spread of the pandemic are symptoms of wide-spread, systemic failures in our social, political and economic institutions.

The psychologist Stephen Pinker, has pointed out that violence itself is a tool of last resort in the human toolkit. The violence of rioters is mostly spontaneous and fueled by anger, flamethrowers and sledge hammers directed at objects belonging to a system they feel has not responded to their needs or concerns. The fact that violence is not the best tool for the job is irrelevant by this point.

Cooler, smarter and more sympathetic heads should actually focus more on what triggered the riots and determine the changes that are necessary to remediate legitimate grievances and hopefully prevent the recurrence of such failures. The reading list offers an excellent beginning for that. Discussing the efficacy and justification for rioting probably doesn't.

To playfully tease, this is exactly what a Flatlander might say. But while you describe the behavior of consciousness, the article describes its other aspects: its shapes, how neurons collaboratively make it and how it is unmade. This not searching for a more feel-good answer, it is a search for deeper understanding which is what science is all about anyway.

Afghanistan was never burgeoning power in recent history. However it was a strategic land-locked asset to other great and super powers throughout history. In the late, Cold War period Afghanistan, once an asset of the Soviet Union, was converted into a land-locked asset to the U.S. following the invasion by the Soviet Union in 1979. The U.S. provided weapons to mujahideen forces fighting against the invading Soviet forces, which ultimately forced their withdrawal.

Unfortunately, following the collapse of the Soviet Union, what had been a useful asset to the U.S. cold-war strategy of containment converted over time into a real threat to U.S. power, (by air, not by sea), as it served as the base of operations by a former mujahideen fighter, Osama Bin Laden, who planned and directed the 9/11 attack against three targets in the U.S.

For some of us at least. Life continues though...

MOVE 'Y' TO NAILED-IT.

The statements the article object to look like informal fallacies: hasty generalization, straw man, availability bias.

I understand what the author is getting at. I myself have read links about new tools and frameworks and might think afterward, "that's pretty cool". Then I'll read the comments section where often I might fall into the trap of hoping others share the same opinion and maybe feel a little hurt and offended when those hopes are dashed. That is simply the nature of any social media platform. And it's probably healthier to let the comments section act as an additional resource on the topic, and one that might challenge our own way of thinking. In this way, comments are not agents of decline in our critical thinking. They are instead, part of its growth process, providing us with differing perspectives that should themselves be evaluated on their own merits and incorporated into our own thinking about the original topic.

I myself can't imagine this site without the comments, especially for additional links that are often provided relevant to the post. They are a great place to deepen one's own investigation of an interesting topic. And I've often been led to other parts unknown to me when reading them.

Evolution happens because of natural selection. It is the narrative of natural selection and does not always have a happy ending. The subtitle of the article is just plain wrong. Of course natural selection explains "the too sexy birds", it just can't predict how long the evolutionary span will be.

Well, according to info about the new MacBook, news of the the function keys' death has been greatly exaggerated.

"Access the function keys by holding down the FN key on the keyboard." -- http://www.apple.com/macbook-pro/

One might also optimistically hope that the touchbar itself has some practical level of re-programmability.