3455
Twitter
RT : I trolled myself too hard. Forgot last year I setup tethering with SSID "No network". Today spent hour troubleshoot…
from twitter
august 2017
Twitter
RT : When you come back from a lunch meeting to find out that GitHub is down
from twitter
july 2017
rjbs's rubric: the simplest thing that could possibly teach me more about postfix
Earlier today, I tweeted:

If I wrote a book, I might call it, "Everything I Learned About Programming, I Learned By Adding More Print Statements"

This is a little funny, but mostly serious. Anybody who has had the misfortunate to watch me try to fix anything has seen my great love affair with printing more crap. When I am deep in bug fixing, my code is brimming with noise like this:

say "about to do stuff"; # debug
do_stuff;
say "just did stuff"; # debug

Later, I'll tell Vim to :g/# debug/d and everything will go back to normal.
Debugging  programming  development 
july 2017
Five Choices You Will Regret Forever | Dr. Travis Bradberry | Pulse | LinkedIn
Our days are filled with a constant stream of decisions. Most are mundane, but some are so important that they can haunt you for the rest of your life.

A recent study from Columbia University found that we’re bogged down by more than 70 decisions a day. The sheer number of decisions we have to make each day leads to a phenomenon called decision fatigue, whereby your brain actually tires like a muscle.

A new study from the University of Texas shows that even when our brains aren’t tired, they can make it very difficult for us to make good decisions. When making a decision, instead of referencing the knowledge we’ve accumulated, our brains focus on specific, detailed memories.

For example, if you’re buying a new car and trying to decide if you should go for the leather seats, even though you know you can’t afford it, your brain might focus on memories of the wonderful smell and feel of the leather seats in your brother’s sports car, when it should be focused on the misery you’re going to experience when making your monthly car payments. Since you don’t have memories of this yet, it’s a hard thing for your brain to contemplate.

"I am not a product of my circumstances. I am a product of my decisions." –Stephen Covey

Some decisions are minor, such as what to eat, which route to drive to work, or in what order to tackle tasks; others are more difficult, such as choosing between two job offers, whether to move to a new city for someone you love, or whether to cut a toxic person out of your life. Regardless of the magnitude of the decision, our brains make it hard for us to keep the perspective we need to make good choices.

Bronnie Ware spent her career as a palliative care nurse, working exclusively with people who were 3 to 12 months from death. She made a habit of asking them about their greatest regrets, and she heard the same five regrets time and time again. By studying these regrets, you can make certain that you make good choices and don’t fall victim to them yourself.

They wish they hadn’t made decisions based on what other people think. When you make your decisions based on other people’s opinions, two things tend to happen:

You make a poor career choice: There are too many people out there who studied for a degree they regret or even spent their lives pursuing a career they regret. Whether you’re seeking parental approval or pursuing pay and prestige over passion, making a poor career choice is a decision that will live with you forever.
You fail to uphold your morals: When you get too caught up in what your boss thinks of you, how much money you think your spouse needs to be happy, or how bad you will look if you fail, you are at high risk of violating your own morals. Your intense desire to make yourself look good compromises your ability to stay true to yourself and, ultimately, to feel good.

The best way to avoid falling prey to the opinions of others is to realize that other people’s opinions are just that—opinions. Regardless of how great or terrible they think you are, that’s only their opinion. Your true self-worth comes from within.

They wish they hadn’t worked so hard. Working hard is a great way to impact the world, to learn, to grow, to feel accomplished, and sometimes even to find happiness, but it becomes a problem when you do so at the expense of the people closest to you. Ironically, we often work hard to make money for the people we care about without realizing that they value our company more than money. The key is to find a balance between doing what you love and being with the people you love. Otherwise you’ll look back one day and wish you’d focused more on the latter.

They wish they had expressed their feelings. We’re taught as children that emotions are dangerous and that they must be bottled up and controlled. This usually works at first, but boxing up your feelings causes them to grow until they erupt. The best thing you can do is to put your feelings directly on the table. Though it’s painful to initiate, it forces you to be honest and transparent.

For example, if you feel as though you don’t make enough money at work, schedule a meeting with your boss and propose why you think you’re worth more. As a result, she will either agree with you and give you a raise or disagree and tell you what you do need to do to become more valuable. On the other hand, if you do nothing and let your feelings fester, this will hinder your performance and prevent you from reaching your goal.

They wish they had stayed in touch with their friends. When you get caught up in your weekly routine, it’s easy to lose sight of how important people are to you, especially those you have to make time for. Relationships with old friends are among the first things to fall off the table when we’re busy. This is unfortunate because spending time with friends is a major stress buster. Close friends bring you energy, fresh perspectives, and a sense of belonging, in a way that no one else can.

They wish they had let themselves be happy. When your life is about to end, all the difficulties you’ve faced suddenly become trivial compared to the good times. This is because you realize that, more often than not, suffering is a choice. Unfortunately, most people realize this far too late. Although we all inevitably experience pain, how we react to our pain is completely under our control, as is our ability to experience joy. Learning to laugh, smile, and be happy (especially when stressed) is a challenge at times, but it’s one that’s worth every ounce of effort.
Bringing It All Together

Some decisions have repercussions that can last a lifetime. Most of these decisions are made daily, and they require focus and perspective to keep them from haunting you.
psychology  life 
july 2017
Amazon - Leadership Principles
Customer Obsession
Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.
Ownership
Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job".
Invent and Simplify
Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here". As we do new things, we accept that we may be misunderstood for long periods of time.
Are Right, A Lot
Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.
Learn and Be Curious
Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.
Hire and Develop the Best
Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.
Insist on the Highest Standards
Leaders have relentlessly high standards - many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high quality products, services and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.
Think Big
Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.
Bias for Action
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
Frugality
Accomplish more with less. Constraints breed resourcefulness, self-sufficiency and invention. There are no extra points for growing headcount, budget size or fixed expense.
Earn Trust
Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.
Dive Deep
Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.
Have Backbone; Disagree and Commit
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.
Deliver Results
Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.
business  leadership  management 
june 2017
What if companies interviewed translators the way they interview coders?
"It's funny because it's true": “What if companies interviewed translators the way they interview coders?”
from twitter
june 2017
Twitter
RT : Next time someone asks me what a career in infosec is like, I'm just going to reply with this picture. Words can't…
from twitter
june 2017
Twitter
RT : Please look at and treasure Dwarf Fortress patch notes for the rest of your lives
from twitter
may 2017
Twitter
This photo single handily saved selfie sticks.
from twitter_favs
may 2017
xkcd: Is It Worth the Time?
how long can you work on making a routine task more efficient before you're spending more time than you save?
automation  humor  productivity  xkcd 
may 2017
rr: lightweight recording & deterministic debugging
rr aspires to be your primary debugging tool, replacing — well, enhancing — gdb. You record a failure once, then debug the recording, deterministically, as many times as you want. The same execution is replayed every time.

rr also provides efficient reverse execution under gdb. Set breakpoints and data watchpoints and quickly reverse-execute to where they were hit.

rr works on real applications such as Firefox, with low overhead. It is being used by many developers inside and outside Mozilla to fix real bugs.
debug  programming  development  software  tools  mozilla 
may 2017
showterm
It's showtime in a terminal near you! Put on your best colours, resize to 80 columns, and let your fingers fly!

Termshows are purely text based. This makes them ideal for demoing instructions (as the user can copy-paste), making fail-safe "live-coding" sessions (plain text is very scalable), and sharing all your l33t terminal hacks.
terminal  collaboration  service 
may 2017
Cats Documentation
Category Theory and algebraic abstractions for Clojure.
clojure  programming  development  functional 
april 2017
The Pyston Blog
Pyston is a performance-oriented Python implementation built using LLVM and modern JIT techniques.
interpreter  python  development  programming 
april 2017
Twitter
RT : 2 unit tests. 0 integration tests.
from twitter
march 2017
Learning From Terminals to Design the Future of User Interfaces — Brandur Leach
RT : ☞ Learning From Terminals to Design the Future of User Interfaces — Brandur Leach
from twitter
march 2017
Untitled (http://fortune.com/2017/03/13/expand-new-market/)
RT : Great article by our own Josh Coates - How to Expand Into a New Market Without Falling Into a Trap:
from twitter
march 2017
Twitter
RT : Any sufficiently advanced regular expression is indistinguishable from magic.
from twitter
march 2017
Twitter
RT : Debugging my own code 🤣😂😁
from twitter
march 2017
Twitter
RT : Regular programmer: "This 1000 LoC method is a bit tedious"
Haskell paper: "This 6 LoC function is a crime against…
from twitter
march 2017
fogus: 10 Technical Papers Every Programmer Should Read (At Least Twice)
10 Technical Papers Every Programmer Should Read (At Least Twice)
Sep 8, 2011

Let me preface this post by saying that no programmer should feel compelled to read any of these papers. I list them because I think that they provide a breadth of information that is generally useful and interesting from a computer science perspective. What you do with that information is your prerogative, including ignoring it completely. Instead, learn what you think is important for what you need to accomplish your job, education, interests, etc.

Inspired by a fabulous post by Michael Feathers along a similar vein, I’ve composed this post as a sequel to the original. That is, while I agree almost wholly with Mr. Feather’s1 choices, I tend to think that his choices are design-oriented2 and/or philosophical. In no way, do I disparage that approach, instead I think that there is room for another list that is more technical in nature, but the question remains, where to go next? In this post I will offer some guidance based on my own readings. The papers chosen herein are not intended to act as a C.S. hall of fame, but instead hope to accomplish the following:

All papers are freely available online (i.e. not pay-walled)
They are technical (at times highly so)
They cover a wide-range of topics
The form the basis of knowledge that every great programmer should know, and may already

Because of these constraints I will have missed some great papers, but for the most part I think this list is solid. Please feel free to disagree and offer alternatives in the comments.
A Visionary Flood of Alcohol
Fundamental Concepts in Programming Languages (link to paper)

by Christopher Strachey

Quite possibly the most influential set of lecture notes in the history of computer science. Left and Right-values, Parametric and Ad-hoc polymorphism were all defined in this paper. Much of the content may already occupy your mind, but the sheer weight of the heady topics assembled in one place is stunning to observe.
Why Functional Programming Matters (link to paper)

by John Hughes

I found this paper extremely lucid on the advantages of functional programming with the added advantage of showing off examples of beautiful code. There are seemingly an infinite number of papers on the topic of laziness with streams and generators, but I’ve yet to find a better treatment. Finally, I’ve always been partial to Reginald Braithwaite’s “Why Why Functional Programming Matters Matters” as a complement to this paper.
An Axiomatic Basis for Computer Programming (link to paper)

by C. A. R. HOARE

I came to this paper late in my career, but when I finally found it I felt like I had been hit by a bus. At the core of the paper lies the following assertion:

P {Q} R

Taken to mean:

If the assertion P is true before initiation of a program Q, then the assertion R will be true on its completion

Where P is a precondition, Q is the execution of a program, and R is the result.

In other words, as long as a program/function/method/etc. receives a set of parameters conforming to its preconditions, its execution is guaranteed to produce a well-formed result. This paper inspired me to explore contracts programming in Clojure, but the proof implications reached in Hoare’s paper run much deeper.
Time, Clocks, and the Ordering of Events in a Distributed System (link to paper)

by Leslie Lamport (1978)

Lamport has been highly influential in the field of distributed computation for a very long time and almost any of his papers on the subject should impress. However, this particular paper is likely his most influential and single-handed defined two branches of study in distributed computing since:

The reasoning of event ordering in distributed systems and protocols
The state machine approach to redundancy

The most amazing aspect of this paper is that after you read it you might think to yourself, “Well, of course that’s how it should work.” Jim Gray once said that this paper was both obvious and brilliant. I would say that there is no higher compliment.
On Understanding Types, Data Abstraction, and Polymorphism (link to paper)

by Luca Cardelli and Peter Wegner

I had originally thought to list Milner’s A Theory of Type Polymorphism in Programming, but thought that a survey paper would be better. I must admit that my own readings have not gone deep into the exploration of type systems, so any additional suggestions would be greatly appreciated.
Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I (link to paper)

by John McCarthy

It’s become a cliche to recommend McCarthy’s seminal paper introducing LISP. I will not count this toward the target of 10, but I would be remiss to excluse it because it’s a great read that is nicely supplemented with the study of a simple implementation of McCarthy’s original specification.3
The Machinery for Change
Predicate Dispatch: A Unified Theory of Dispatch (link to paper)

by Michael Ernst, Craig Kaplan, and Craig Chambers

Describes a method for dispatching functions based not on a static set of rules, but instead as the traversal of a decision tree that could be built at compile-time and extended incrementally at runtime. What this means is that dispatch is controlled and adapted based on an open set of conditions describing the rules of dispatch. This stands opposed to the current popular trend of languages whose dispatch is hard-coded and not open for extension at all.
Equal Rights for Functional Objects or, The More Things Change, The More They Are the Same (link to paper)

by Henry G. Baker

At the heart of Clojure and ClojureScript’s implementation is #equiv that is in turn based off of Henry Baker’s egal operator introduced in this paper. Briefly, equality in Clojure is defined by equality of value, which is facilitated by pervasive immutability. Equality in the presence of mutability has no meaning.
Organizing Programs Without Classes (link to paper)

by David Ungar, Craig Chambers, Bay-wei Chang, and Urs Hölzle

The greatest crime perpetrated in the name of JavaScript is the propensity for every framework, library, and trifle uses the prototypal inheritance capabilities of the language to implement class-based inheritance. I propose that this behavior stunts the power of JavaScript. However, the class-based mentality is pervasive, and is only likely to grow stronger as JavaScript moves toward “modernized” data-modeling techniques. Having said that, I love the prototypal model. It’s flexibility and simplicity is astounding, and this paper4 will show how it can be leveraged for practical purposes. While a design oriented paper, I think that the knowledge is contrary enough to pop-programming to warrant inclusion. Self is a fascinating language on its own merit, but especially in that its influence5 on modern dynamic languages is growing ever more pervassive.
I’ve Seen the Future, Brother: It is Murder
Dynamo: Amazon’s Highly Available Key-value Store6 (link to paper)

by Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall and Werner Vogels

It’s rare for a paper describing a system in active production to influence the state of research in any industry, and especially so in computing. Papers describing thought-stuff are pure and elegant while “real-world” systems tend to be ugly, hackish, and brutish, even if they are rock-solid otherwise. The case of Dynamo is quite different. That is, the system itself is based on simple principles and solves a hard problem, highly available and fault-tolerant online database storage, in an elegant way. Dynamo was not a new idea, but this paper is necessity as we move forward into the age of Big Data.
Out of the Tar Pit (link to paper)

by Ben Moseley and Peter Marks

Now we reach my favorite paper of the bunch – one that I try to read and absorb every 6 months (give or take). The gist is that the primary sources of complexity in our programs are caused by mutable state. With that as the premise, the authors build the idea of “functional relational programming” that espouses minimizing mutable state, moving whatever remains into relations, and then manipulating said relations using a declarative programming language. Simple right? Well, yes it is simple; and that’s what makes it so difficult.

This list should be a good start, but where to go next? My personal approach is summarized simply as: follow the bibliographies. If you like any of these papers then look at their bibliographies for other papers that sound interesting and read those too. Likewise, you can use services like Citeseer and the ACM Digital Library to backtrace citations.

Happy reading.

:F

Apart from a spectacular ear for music, Mr. Feathers is also a fount of wisdom, including this gem from the linked post:

When I first started writing, one of the pieces of advice that I heard was that you should always imagine that you are writing to a particular person.



Design is a vastly overloaded term, but it’s the best word that I can think of. Suggestions for something better? ↩

A have some ideas for a Lisp-centric essential papers list also, but have not yet formalized the content. ↩

It was difficult picking a paper from the treasure-trove that is the comprehensive list of Self publications. These papers represent the vanguard of performance in dynamic languages. ↩

Although Self does not hold a monopoly on dynamic performance revolutions. Smalltalk implementations have also driven innovation in said space, and a taste for this influence is found in Efficient Implementation of the Smalltalk-80 System by Peter Deutsch and The Design and Evaluation of a High Performance Smalltalk System by David Ungar. ↩

The Dynamo paper is probably the most controversial choice … [more]
paper  links  development  programming 
march 2017
Pony - High Performance Actor Programming
Pony is an open-source, object-oriented, actor-model, capabilities-secure, high performance programming language.
language  programming  development 
march 2017
Twitter
RT : You are only making him more powerful
from twitter
march 2017
Lingon - Peter Borg Apps
An easy to use yet powerful app to run things automatically

Lingon can start an app, a script or run a command automatically whenever you want it to. You can schedule it to run at a specific time, regularly or when something special happens.

Lingon can also make sure that an app or a script automatically restarts if it crashes.

Lingon X is based on the great Lingon 3 and extends it with new features like running jobs as root and on multiple dates. It can also monitor all jobs in the background and show a notification when something changes. It is now even easier to use yet much more powerful.
mac-app 
february 2017
Twitter
RT : Be the third donkey you want to see in the world.
from twitter
january 2017
Lobsters
Lobsters is a technology-focused link-aggregation site created by joshua stein and launched on July 3rd, 2012. It borrows some ideas from, while also attempting to fixing problems specific to, websites such as Hacker News, Reddit, and Slashdot.
development  programming  news  tech 
january 2017
Twitter
RT : This is a pace I can keep up with!
from twitter
january 2017
Twitter
RT : God showed how much he loved us by sending his one and only Son into the world so that we might have eternal life.…
from twitter
december 2016
Twitter
RT : 🤔 If a snake was responsive...
from twitter
december 2016
Instagram
RT : 🤔 If a snake was responsive...
from twitter
december 2016
Better Code Hub
Step 1: Connect with GitHub and select a repository
Step 2: Check your code against 10 guidelines
Step 3: Any crosses? Start improving!
Step 4: All green? Your code is future-proof!

The 10 Guidelines for Maintainable Software

1. Write Short Units of Code

Short units are easier to understand.

3. Write Code Once

Duplicated code means duplicated bugs and duplicating changes.

5. Separate Concerns in Modules

Modules with a single responsibility are easier to change.

7. Keep Architecture Components Balanced

A balanced architecture makes it easier to find your way.

9. Automate Tests

Automated tests are repeatable, and help to prevent bugs.

2. Write Simple Units of Code

Simple units are easier to test.

4. Keep Unit Interfaces Small

Units with small interfaces are easier to reuse.

6. Couple Architecture Components Loosely

Independent components can be maintained in isolation.

8. Keep Your Codebase Small

A small codebase requires less effort to maintain.

10. Write Clean Code

“Leave the campground cleaner than you found it.”
programming  development  maintainability  tools  analytics 
december 2016
Twitter
"Let God be true though every one were a liar." (Romans 3:4)
from twitter_favs
december 2016
« earlier      
3d accessibility actionscript algorithms all_android analytics analyzer android android_2.1 android_apps android_dev announcements apache api app applications apps art article articles as3 automation aws backbone backup bash book books browser business c c++ canvas challenge chat christianity cli clojure cloud cms code collaboration communication community company comparison compiler computing courses cpan css data database debug debugging demo deployment design development devops docker documentation editor education elasticsearch encoding encryption entrepreneurship erlang explore facebook featured_article feedproxy finance firefox flash font format framework free freelance fun functional game gamedev games general_news generator git github go golang google government graphics graphite graphs gui hardware haskell haxe health history hosting how-to html html5 http humor ide ie internet interpreter interview jabber java javascript job_board jobs journal language languages learn library life links linux lisp logs management math messaging missions mobile modernperl monitoring mozilla music nagios network news nodejs nosql ocaml online_book open_source opensource optimization os oscon paas patterns pdf performance perl perl5 perl6 php plugin politics postgresql productivity profile programmers programming project-management psychology puppet python qa queue reactive read reference releases religion remember remote rom rss ruby samsung_moment scala sdx search security server service share shell social software software_news softwaredevelopment ssh ssl standards statistics storage svg sysadmin taskrunner technology technology/internet terminal testing tools tutorial tutorials ui uncategorized unicode unix use utf-8 ux video vim virtualization visual_design vm web web_developers web_tech webdesign webdev work xml

Copy this bookmark:



description:


tags: