“Country singer Willie Nelson shares a joint with actor John Belushi as he pinkie swears with a Hells Angel at the Lone Star Cafe. New York City, circa 1980.”

blake kathryn
🪼
Peter Solarz

oozey mess

tannertan36
almost home
Lint Roller? I Barely Know Her

No title available
Acquired Stardust
hello vonnie

JBB: An Artblog!

ellievsbear
I'd rather be in outer space 🛸
h

Discoholic 🪩

Andulka
taylor price
todays bird

pixel skylines

PR's Tumblrdome

seen from United Kingdom
seen from T1

seen from Malaysia
seen from United States
seen from Netherlands
seen from United States
seen from United States
seen from Ireland

seen from United States
seen from Türkiye
seen from United States

seen from Türkiye

seen from United States
seen from Türkiye
seen from Brazil
seen from Türkiye

seen from United States
seen from United States
seen from Saudi Arabia

seen from United States
@leongersing
“Country singer Willie Nelson shares a joint with actor John Belushi as he pinkie swears with a Hells Angel at the Lone Star Cafe. New York City, circa 1980.”
You worked hard this year — #TreatYoSuperSelf. #FathersDay
Brian, I really want to create comics. Unfortunately though I'm awful at drawing and illustrating, how can I improve?
Practice.
also, let’s get over this ‘I can’t draw a thing’ horseshit once and for all.
That’s not an excuse. you can make comic books with stick figures, found art, dots, money…
all you have to do was tell your story with clarity.
and think about how most famous rock ‘n roll singers are not actually technically excellent singers. in fact most artists and filmmakers who really touch us do so with technically flawed art. it is the flaws that move us.
the best cartoonists and comic book creators are not always the best drafts people. they are expressing themselves through their art, sometimes messy, sometimes childlike, sometimes seemingly amateurish but still it moved us…
stop standing in your own way. make some pages. see what you have to offer.
The Last Thing We Need
From the moment of our birth we are told the difference between right and wrong, good and evil and are given measuring sticks for success. The need to accurately predict patterns of behavior have led to the proliferation of the species. But when do we stop? When do we know that the wisdom that led us safely out of the trees is now obsolete and makes us more susceptible to subjugation. How hard can we push outward into the pathless forward before we recede back into the familiar, begging for subjugation again?
“Uncle” Bob Martin recently wrote a post bemoaning the absence of a “foreman” role on his projects. His points are riddled with conjecture and hollow claims that are better at generating straw-men (reactionary and off-topic) arguments than candid, open conversations about the task of writing and maintaining software. Bob is not evil. He’s a pretty cool guy when you pair with him. I simply don’t agree with him. Mostly I think it’s harmless and often healthy to not agree with your contemporaries. However, this time I feel compelled to speak. With that know that I perceive Bob as someone who simply believes in something that I do not. Bob believes that process, rules and laws will save us all from our selves. Bob needs you to believe you need it too or else how can he sell you his new book on the subject of him saving you from yourself? When he describes your ailment, it’s amazing how close at hand his remedy is.
This is the dirty secret that we don’t want to be true tomorrow. We’re afraid that the world is exactly as he sees it. That the “construction site” would fall apart without the authoritarian eyes of the foreman. This person that we universally know to be correct; whose judgement is without question and whom we can lean on when we inevitably see how inferior we all truly are. Sounds just like the ethos of someone with a solution. Someone who needs you to accept their words and governance without pause or question of hesitation. Sure, this person, this foreman could be a “rotated” roll but then someone whom we don’t trust will become powerful and we’ll have to live a lie while they are in charge. Best to choose the best person for the job now and get right to the subjugation.
Bob asked the question “why don’t we have this guy?” and I have the answer. Because that guy is an asshole. We don’t need that guy. Not one of us has the power to say what’s good or bad in all cases. At this point in hour history we know that we’re the sole purveyors of truth; software is subjective at best and the sooner you find people that you get along good enough to communicate with the sooner you can to be effective and build something.
In his follow up post, Bob adopts a tone of genuine shock that we all didn’t just line right up to get another boss to report to and reveals the truth behind his original post. That someone’s spouse was dying and they were “distracted” by life so their work was shitty. If any other person on the team was feeling, empathetic human being then this person would have a champion and others would move heaven and earth to guard this team member in the context of the team so that they can deal with their life. The company doesn’t need another boss to report to. The company needs to know that someone who once did great things is going through some hard times and they will come out of it and build even greater things. They don’t need a foreman to facilitate this. They need a team. They need a family. They need communication. They don’t need another foreman. Bob’s 2 articles are a folksy, colloquial pseudo-allegory on the state of communication in software teams.
tl;dr It’s bad. No shit.
If your teams are communicating, in the way that works for you (for some, email is enough. Others have daily standups and are co-located, etc) then these issues would have come up and the team, no matter how it is structured would rally around their friend and work to pick up the slack for as long as they were able to. That’s what good people, people that you hire into six-figure software salaries, people that you pay for health insurance as an employer, people that make your software, your company and your life (and the lives of your customers) better. You love them and you value them and you want them to succeed. In fact, as a team, owner, peer, customer, you want them to succeed. These, highly educated, highly motivated, creative and intelligent people do not require any further instruction from you.
Bob will inevitably lump me into the group of radicals to don't live in "the real world" and don't know how "software is built today". That's fine. It's sad because it means that he's better at writing than reading. You're saying that a foreman is the best way to ship software as a team. I humbly submit that your view is myopic and represents a system of self-imposed rules that neither prove or disprove your claims but instead give a predictable role for all blame and responsibility. This is the problem. Not the foreman but the thinking that goes into deciding you need one.
The last thing that any thoughtful, creative human being needs is another system to game. In America, in particular, we’ve come to choose our myths over natural truths so wholly that we can no longer logically discern fact from fiction. We build simulacra that we think are simulations of real life but they’re not. Adding someone else to think for us is not the answer. Adding more rules, laws and governors into our ranks prevents us from seeing the truth: that Software Developers are the smartest people in your organization and our continued desire to lock them down, over monitor them, in other words, coddle them into mindless, frustrated, automatons will be our ultimate subjugation when they inevitably rise against and reject all the foremen.
The Great and Terrible Burden of Choice
Suzan blogged her thoughts on restraint in the modern era in her usual insightful and thoughtful way. It reminds me of a thought I was having this morning while gathering the new morning's sunlight through the slit in my blinds.
140 characters can ruin a life. 140 characters can save a life. 140 characters can inspire others. 140 characters can depress others. 140 characters to get it right. 140 characters to get it wrong. 140 characters to find love. 140 characters to destroy love.
Here-in lies the hidden dilemma of our time: We are the engineers of our own fate. The weak want others to make those choices for them. They trade uncertainty, fear, tension and courage for dogma and idiom. They will gladly kill the next herald to cross their newly understood and easily digestible wisdom in the hope that it will silence the fear in their belly; the fear that they are, in fact, every bit the fraud they fear they may be. This fear, armed with dogmatic purpose turns the thinking, feeling, sentient into a mob joining, pitchfork wielding, embarrassment to free/thinking society.
There's no industry immune. There's no community unaffected. There is no escaping the universal need to feel above it all. Unfortunately, this freedom does not come from consensus and it does not come without the risk of harm.
The choice, the great and terrible choice, is that you must be true to yourself and what you feel is right at all times. Even when that is inconvenient. Even when it means you may stand to lose all possessions and relationships. It means taking a punch and never throwing one. It means doing that which everyone knows is right but lacks to courage to make. It means being judged harshly today to be vindicated tomorrow... if ever.
I have had my code called "crazy", "arbitrary", "whimsical" by those who both knew what I was doing and those who did not. Fortunately, I was strong enough to hear the criticism, decide if they could see what I saw, and if not, simply say thank you for their time and care and move on.
You can choose to be bothered by everyone who doesn't understand your point of view. You can choose to give away your own point of view for someone else's. One of these is comfortable, safe and leads to a good life. One of these choices is not. Both are worth making and everyone does. How you choose will determine who you are. You can change your mind at anytime. All it takes is understanding the great and terrible burden of choice.
Permission granted
I don't know what it is with my generation in America these days but I find myself acting like a broken record. Reminding folks of the same things over and over again. I decided to make it simple and share it with you now.
There is no one to gain permission from. There is no one to impress. There is only you… now.
The common response when I ask what someone is doing is “well, I'm doing x but I really want to do y.” to which is reply: “then do Y. now.”
“well… [enter excuse here]”
Let me make this perfectly clear. You are exactly what you practice. You are only what you're doing right now. Not what you dream to be doing, not what you think you will become, you're this… Right now. Every platitude and excuse you give, every lie you tell to me about your hopes, dreams and aspirations is a myth you've concocted in order to deal with the fact that you're no closer to obtaining them today than you were the first time you uttered the words to yourself.
That's ok. You are not a failure unless you believe that it will happen by magic. Even then you're not a failure, you're just in denial of the truth. The truth being that you're in complete control of your life. You can choose to be whom you want and take steps to ensure that the world sees you. Do not wait for permission, do not validate your life until you're living it. We are obsessed with our own histories. That is a waste of time. What good is planning how you want your story to be told if you're not out living enough of a life to merit telling?
Be you now. Whatever that is, whatever that means, stop waiting for someone to let you do anything, go out and do it. Now.
So for those looking for someone to help them start, allow me to be the first person you thank in your novel's liner notes, the first shout out on your hip-hop mix tape, the first name listed in the thank you page of your new web app. I hereby grant you the permission to start doing whatever you need to do to be the person you claim you want to be. Anyone hating on you, any critics you meet along the way, tell them thanks for stopping by and send them and their negativity packing. You're walking the path you've always intended to walk and they are scared by the sound cracking their ears, the wind brushing their cheeks, the light flashing before them as you pass them by.
Love - CodeMash 2012 Pecha Kucha Slides
For those who requested the slides from my Pecha Kucha talk at CodeMash 2012, here you go. All rights for photos belong to their perspective holders. For those I could not find copyright info, please feel free to get in touch and I'll provide full credit as required by your licenses. Thanks! Leon link: http://public.iwork.com/document/?d=Love_-_CodeMash_2012_Pecha_Kucha.key&a=p79052775 browse here:
I do live in a gorgeous corner of the planet
My Perception of CoffeeScript
CoffeeScript is something that I've watched for a very long time and my first attempt at using it in a project was early in its development and while I wanted to commit patches, reading some of the conversation around the purpose and overall goals made me realize that I simply see JavaScript differently than the author (Jeremy Ashkenas, whom I do not know but would LOVE to have a drink with (alcoholic drink or otherwise) and pick his brain, if anyone knows him and would kindly introduce us at a conference or something :). I'm buying, btw!). Different is wonderful and should be celebrated; encourage! Which is why I am loathe to write an article like this but after being mis-represented on twitter for the ump-tenth time, I decided it would be in my best interest to attempt to articulate my perspective first hand.
CoffeeScript makes a wonderful assertion of referential transparency in it's scoping rules. By eliminating the "var" keyword and wrapping the entire context in a closure, it's impossible to unwillingly scope variables globally nor can you augment outer scopes in an inner context through assignment which is fantastic. So far I'm loving this! Throw in all the syntactical sugar, iterators, and list comprehensions and hot damn if I didn't think our brilliant friend was trying to "haskell-ize" JavaScript! Until I saw the class keyword. In this, my heart sunk. Then I saw a differentiation between "->" and "=>" in which the very notion of the scoping rules being encapsulated by the language seemed to be leaking back into the developer's lap. Finally, the back tick (`) to interpret something as JavaScript inline. These 3 items are significant concessions on the overall vision that give me pause and I begin to ponder "In what context, would I need a back tick?" or "If classes ape their statically typed brethren of Java, then, idiomatically, is the idea that I should augment them by reference? and if so, is it even possible to do so given the implementation of var without the overhead of accessor methods? And if so, doesn't that just kill all the cool stuff that came before it?"
All of these questions came up in the first project I used Coffee in. It's not the that Object modeling metaphor used in CoffeeScript is bad, it's just overly object-oriented and builds on OO style inheritance. JavaScript has a built in mechanism for attaching functions to any instance, like composition aka "mix-ins", which can lead to high degrees of function reuse outside of any domain logic that may be encapsulated by a class to begin with. JavaScript's Prototypical inheritance model is so simply in it's implementation that it actively discourages large object graphs from being constructed through traditional OO methods. Yet CoffeeScript is engineered to dismiss this compositional simplicity in exchange for a more complex albeit more familiar OO style inheritance model. This, in my opinion, makes CoffeeScript less transparent that JavaScript, increases the complexity and introduces an amazing amount of generated JavaScript code into your runtime interpreter that contains little value over JavaScript and no compile time optimizations (closures don't count, scoping doesn't count). This means that CoffeeScript is not a language with it's own identity and purpose but rather a bridge to another one. CoffeeScript classes have attributes and properties that are encouraged to be mutated by reference so a language contrivance was devised (@) to allow OO style encapsulation while still trying to provide Functional referential transparency in anonymous contexts… wrap your head around that. I can't. {} is an object, any object, in JavaScript. What good does it to force it into an "Animal" type that extends another and another and so on? So that I can know that {name:"Leon"} can be safely mutated in it's scope but not outside of it? CoffeeScript's Class system and inheritance model adds un-needed complexity in a way that I've yet to comprehend the inspirations for. I'm going to scope the rest of my article to deconstructing it and leave some of the other issues for another article.
Ironically, if the idea was to mix-in existing functionality via functions, Jeremy wrote a much more simple and elegant version of this in 6 lines of code for underscore.js (yes, he's the author of both!) in the extend method; extend is simple, idiomatic, and encourages the construction of tiny and discrete units of code that can become polymorphic as the need arises. Here's the extend function in all it's glory…
_.extend = function(obj) { each(slice.call(arguments, 1), function(source) { for (var prop in source) { if (source[prop] !== void 0) obj[prop] = source[prop]; } }); return obj; };
Right?! RIGHT! It's awesome! that means I can compose my objects (as late as runtime!) from existing objects, objects that don't exist and objects I don't even know exist yet. Each composed to be as simple or complex as the domain allows, without the increased overhead of the OO object model of CoffeeScript's "class" implementation. I can give functions to objects, properties, anything my heart desires, whenever I want.
I would love to juxtapose the implementation of the class based inheritance in Coffee to the simple extend in _.js but the comparison is orthogonal and unfair. Instead, I'll compose methods onto a tiny object from the class example in the CoffeeScript docs. First, let's examine the output of the Class results from this CoffeeScript:
class Animal constructor: (@name) -> move: (meters) -> alert @name + " moved #{meters}m." class Snake extends Animal move: -> alert "Slithering..." super 5 class Horse extends Animal move: -> alert "Galloping..." super 45 sam = new Snake "Sammy the Python" tom = new Horse "Tommy the Palomino" sam.move() tom.move()
The generated JS:
var Animal, Horse, Snake, sam, tom; var __hasProp = Object.prototype.hasOwnProperty, __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor; child.__super__ = parent.prototype; return child; }; Animal = (function() { function Animal(name) { this.name = name; } Animal.prototype.move = function(meters) { return alert(this.name + (" moved " + meters + "m.")); }; return Animal; })(); Snake = (function() { __extends(Snake, Animal); function Snake() { Snake.__super__.constructor.apply(this, arguments); } Snake.prototype.move = function() { alert("Slithering..."); return Snake.__super__.move.call(this, 5); }; return Snake; })(); Horse = (function() { __extends(Horse, Animal); function Horse() { Horse.__super__.constructor.apply(this, arguments); } Horse.prototype.move = function() { alert("Galloping..."); return Horse.__super__.move.call(this, 45); }; return Horse; })(); sam = new Snake("Sammy the Python"); tom = new Horse("Tommy the Palomino"); sam.move(); tom.move();
Now here's the same re-written in pure JavaScript.
function move(aDistanceOf){ var it = this.name || "It"; if(arguments[1]){ alert(arguments[1]); } return it + " moved " + aDistanceOf + " meters."; } var snake = { name: "Sammy" }; var horse = { name: "Tommy" }; move.call(snake, 5, "Slitering"); move.call(horse, 45, "Galloping");
That's it. Now, I know what you're thinking, "Leon, please, the Coffee example is contrived and doesn't represent real world domains." You're right and so is mine as a result. "But you also didn't create real domain models." Also right, because I didn't have do, nor would I ever want to. Therein lies my point. Sometimes a struct is a struct and not an class. The difference that I'm desperately trying to convey in this overly simple context is that by leveraging FP over OO one can provide not only a more dependable abstraction but when combined with JavaScript's inherent flexibility as a language, we can achieve true referential transparency and polymorphism. As my domain continues to increase in complexity I'm not concerned about constantly redefining my object graph, instead, I pass them through the move function as I would any valid javascript object to achieve my end goal. When I encounter a task that move does not make sense for, I can create a different function, add additional arguments (for say, callbacks) or refactor this one (be sure to run those tests!)
In terms of pragmatic interface design, I'm not impressed by the fact that I have to think of the "move" function as only pertaining to that model's object graph. It's an abstraction that is bound (and encouraged) to leak. This is a fundamental difference between OO and FP and the crux of my frustration with CoffeeScript. FP encourages building small functions that do not mutate state and can be bound together as needed to perform a task whereas the OO philosophy is to encapsulate and achieve polymorphism through interface or contract. The more dynamic your context the more OO's encapsulation paradigm, as seen in the inheritance model, leaks and defies it's 3rd and most important tenant: Polymorphism. Even these 2 contrived examples above, if I look at the majority of CoffeeScript I've seen written at EdgeCase (including my own… guilty.) there has become this Java-esque DTO on the client side that takes a pure, evaluated, ready to go json object that is sent back from the server, xhr style, and translates it into a "Snake or Horse" instance. for what? This is where Jeremy's claims to "just as fast or faster as the JavaScript you'd write" fall down. The overhead encourages more complexity, more computation and ultimately more indirection.
CoffeeScript sees the world through OO's eyes. When I see JavaScript, I find beauty in it's ability to be a dynamically typed Functional programming language. (that's your TL;DR;, friends.)
This doesn't mean CoffeeScript is BAD, poorly written, without merit. In fact, I encourage you all to check it out and decide for yourselves. I think you'll find a clean, well crafted lexer and a sweet tokenizer written in JavaScript. That's a pretty cool thing in itself; something worth celebrating. I simply find that outside of an academic context I don't prefer it over JavaScript. JavaScript's function keyword and curly brackets aren't "ugly" to me, they are useful indicators of code smells. Do you have too many of them in a row? Time to break down your functions. This is not a problem with JavaScript, this is a problem with developers. CoffeeScript's encouragement of OO patterns over Functional ones seems, to me, misguided in it's current form which is not a compile-time machine or VM optimized language alternative to JavaScript but a bridge that seeks to help you write better JavaScript at the expense of gaining the wisdom of what that even means.
If you're a fan of OO you're going to love CoffeeScript from day one, guaranteed. If you've never tried to see the world through Functional glasses then I assert that you're going to be missing out on a few beautiful vistas. Even if you go back to OO, give your solution a try in a functional style before turing JavaScript into Ruby or Python just because it feels more comfortable. If you can't do it on this project, try it at home, or better yet, learn Erlang or Haskel or F# or Clojure and try to see the world that JavaScript sees before you turn it into something it's not.
I hope you enjoyed this article. It was painful to write because I want to see more wonderful things from authors like Jeremy (seriously, _.js is genius.). While CoffeeScript is not for me, it's obvious that many others find value in it and that's really all that matters.
Thank you, Steve. For Everything.
WHAT IS YOUR FAVORITE INANIMATE OBJECT?
my iPad. :)
Software Dogma
"Don't try and bend the spoon. That's impossible. Instead try and realize the truth… There is no spoon. Then you see that it is not the spoon that bends, it's only yourself."
Jim has a new blog post that solidified a few of my own thoughts on the age old saying I hear bandied about over and over at software conferences: "You can change where you work or you can change where you work." A phrase that has only recently revealed its inner wisdom to me.
This statement illuminates a simple paradox. It reveals the person sharing it to be someone who has decided to change the environment around them in spite of direct opposition rather than to walk the path that they'd like to actualize. It's rarely imparted in the other direction unless to hopefully reveal it's inner wisdom from an outside perspective one more time. The paradox in this choice is that while it seems to provide an easy answer to a complex problem it's really indirection. It's denial. It's a solution that lacks balance and reveals the individual making it to be in a state of waiting; not ready to embrace the path they wish to travel; highlighting the lack of understanding of themselves and why they are not at peace with the very task that used to provide such joy. This person and the opposite that they've created (manager, organization, team, so on) cannot accept the other and therefore balance cannot be achieved. They believe that fighting the opposite will be rewarded. They arm themselves with the texts and teachings of Software Practice Prophets and hold to these teachings with the fervor of a true dogmatist. Thus resulting in devaluing of the individual as they see their life not as it is but how they wish it could be. Manifesting in shame, loss of motivation/hope compounds like bad debt and as they fight a fight that they don't even understand, knowing that once the others see the world through their eyes everything with be…perfect. Continually perpetuating the notion that there is a single path to enlightenment. That holding stalwartly, doggedly to the dogma will provide the enrichment of life that they so desperately desire. This if, of course, paradox. The 2 opposing sides must find balance and in this situation they cannot.
This is a choice. If there is wisdom to be gained through the teachings of a guide then that wisdom must be gained through experience. The wise man's role may be to reveal to you a door to your path that you may not be able to see, to leave footprints behind from their own experience. The wise walk the path, with doubt, with questions, with fear, with hope, with joy, with passion. They walk with the full spectrum of human emotion and experience and they find others along the way to balance themselves and share perspective on the journey.
Jay-Z puts this perfectly in Renegade: "No lie, just know I chose my own fate I drove by the fork in the road and went straight"
Jay recognizes there is a path, by those that walked it or want to control his experience but chose to forge his own path. The artifacts are, of course, new music and new paths for others to recite back as dogma. Which is, of course, entirely their choice. He made his, others must make theirs.
I wrote down a phrase after a terrible conference experience that I had that I never understood until recently.
"Dogmatist believe. Messiahs doubt."
It's not a quote from anything, just a thought I had while reading books over the years where I noticed a trend in both religious, spiritual, philosophical texts and from the messages I was hearing at the many conferences I used to attend. This seemingly paradoxical juxtaposition was of great fascination to me at the time and it wasn't until recently, as I began to inherit the codebases of some of the very people I have come to respect from afar. My dogma had been shattered. You see, I had come to worship the dogma of idioms like TDD, Test-First, Test everything, patterns patterns patterns and more patterns. At first I was angry. "How could this person who lectured me for an hour at that conference about their clean code practices produce such utter contradictory drivel!?" That anger lead, inexorably, the its only conclusion: I missed the point. I was worshiping the messages of wisdom, seeing the footprints on the path as truth but that's ridiculous. That's dogma. They were, in truth, simply how someone achieved their goals repeated back. There was no wisdom inherent to the words or the individual who shared them. They were the living representation of perspective from someone walking their own path. I was using it as a buffer to prevent me from doing the very thing that would be the most beneficial: Making up my own mind.
My choices are my own and the wisdom they provide is only for me. When I am faced with the notion of "change where I work or change where I work" I realize that I've already made the choice. Understanding why I made it is the challenge and the only way to gain that wisdom is to simply start walking my own path.
"Don't try and bend the spoon. That's impossible." or as I hear it now: "Don't copy me for what I do. See past this illusion and realize the truth therein."
"Then you will see that it's not the spoon that bends. It is only yourself."
Of course. There is no spoon.
Mitch's documentary looks amazing. I can't wait to see how it comes out!
I just saw this today and loved it. Enjoy.
Web frameworks are a dime a dozen these days, and they all promise to deliver enormous productivity boosts without limiting your creativity. The darker side of it is that while they often allow you to create applications very quickly, sometimes they make it pretty hard to...