found drama

get oblique

review: Java Cookbook

by Rob Friesel

Java Cookbook (3rd Ed.)Ian Darwin’s Java Cookbook is out and it’s a great resource for developers working in Java that are out there and scratching their heads asking “How would I go about…?”

The thing that makes Java Cookbook stand out is its comprehensive scope. Darwin has done an excellent job of gathering a wide array of common problems faced by Java developers and presenting solutions to those problems that are decipherable using just the language’s standard library features. (Which isn’t to say “ignore libraries” — just that there are few (any?) recipes in this cookbook that require external dependencies.) By and large, the recipes are practical and are organized into sensible categories. This isn’t a book that I’d recommend you read front-to-back, but if you’re programming in Java, it’s worth having it handy to help kickstart your thought process on a number of different problems. (Plus, 3rd edition has been updated to include solutions that highlight Java 8 features.)

In addition to the above, it’s worth noting that while Java Cookbook isn’t a great book to learn from, that if you have stumbled your way into Java with an otherwise solid software engineering background, that you could use it as a leg-up or crutch while you’re otherwise getting up to speed.

Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.

what we talk about when we talk about type-safety

by !undefined

Thought-provoking piece by Stephen Kell on type systems, type-safety, and what a lot of people mean when they talk about it: Seven deadly sins of talking about “types”.

My main takeaway from Kell’s piece was that type systems, like everything else in programming/computer science, comes with trade-offs and though there are many advantages to using a language with good type-safety, it’s also not a panacea and to believe so is dangerous and naïve. Part of what’s interesting here, is that he claims that many people are simply semantically wrong when talking about “types” when what they are discussing is actually compile-time checking, use of predicates, or other abstractions.

surrounded by all that framework magic

by !undefined

A very worthwhile read from Keith Rosenberg: Why I Don’t Want Your JavaScript Framework but I Love You.

If there’s a tl;dr then it’s this: choose when to use a framework, not which framework – if you choose any framework at all, and/but/so when you do: take the time to get to know the source code, not just the docs.

Continue reading →

trifleJS

by !undefined

TrifleJS

RE: trifleJS: “Headless automation for Internet Explorer”

Which looks like a port of (part of) the PhantomJS API to an environment that wraps IE by way of some .NET controls. (Also: V8 is in the mix somehow and/but/so not sure how that changes the equation w/r/t/ if the IE runtime is using that as the underlying JS interpreter or if it’s just some kind of bridge.) See also: SlimerJS : Gecko :: PhantomJS : WebKit

And speaking of SlimerJS: its API is also “PhantomJS-compatible” which raises the question of whether we need to be doing some work to create a “headless browser scripting” standard that we can reliably lean on, or if we’re just going to accept that PhantomJS came first and everyone is going to ape its API.

the boring designer

by !undefined

Cap Watkins, The Boring Designer:

The boring designer chases the right idea over their idea every time. They respect their team and will try almost any idea (whether on a whiteboard or in Sketch or in code) that gets thrown their way. Instead of arguing about whose idea should win, the boring designer tries all the ideas and even elevates others’ ideas in the process. The boring designer abhors groupthink and being told “yes.” They consistently request feedback and new ideas. And as a result when they feel super passionately about their own idea, the team listens.

So many of these points translate (or apply directly) to lots of other leadership roles, technical or otherwise.

what’s the problem with JSON?

by !undefined

Ben Hughes, JSON and the Arguments:

tl;dr: General argument is that JSON is hard to read and the format spec explicitly disallows comments. The former point I disagree with completely; 1 the latter point is fair and/but that’s also why I think something like a Gruntfile is good because it uses functions for configuration (but a Gruntfile is hardly project configuration 2). And/but/so I’m surprised XML wasn’t brought back into this (except in that brief cast-off) because say what you will about XML w/r/t/ verbosity &c. but it’s a hella rich format. 3

  1. I don’t get it when people say that JSON is hard to read. It’s no more or less hard to read than (say) YAML.[↩]
  2. I.e., build configuration is not project configuration.[↩]
  3. Not that I’m a big fan of XML but it is hard to beat if you’re looking for something with rigid, well-defined structures, comments, element-level metadata (e.g., attributes), schemas, validation, etc.[↩]

HELP WANTED: User Experience Researcher/Designer

by Rob Friesel

Job Type: Full-Time/Regular
Job Level: Mid-Career (2+ years)
Years of Experience: 10+ Years
Level of Education: BA/BS/MA/PhD/MFA/DDS

Job Description

Metavaprwaresoft.ly, a fast-growing VC-backed lean start-up, is seeking experienced, skilled, and passionate innovative interactive interface interaction designers who dive in head-first and seize challenging applications by the horns. We are looking for developers that blur the boundaries between web, mobile, mainframe CLI, and native design problems. You feel right at home in storyboard war rooms and can recite the Lean UX Design Research Manifesto by heart. If that sounds like you, then we want you as part of our team to help continuously iterate by designing, researching, analyzing, redesigning, refactoring, releasing, and integrating the user experience (“UX”) for our valuestream development “spike cycle”.

Your work here will positively impact the empowerment in the daily lives of millions and we will rely on your killer sense of style, your keen insight, and your on-going drive to innovate emergent themes while keeping our product pipelines fresh, relevant, and valuable to the nuclear core of our customer base. If you are the right candidate, relocation expenses may be irrelevant.

Experience and Skills

DON’T SHOW UP WITH ANYTHING LESS!! Here’s the war chest of tools we expect you to bring to the on-boarding:

  • A real-time updated portfolio that demonstrates not only a passion for user-centric design, but a passion for quality visual aesthetics.
  • Next-level expertise in best-of-breed rapid-prototyping tools (Balsamiq, WebZap, CompassStrap, jUnit, whiteboard and markers, literally a napkin with pencil & paper).
  • Maven-like grasp of bleeding-edge design trends and techniques.
  • Intimate knowledge of HTML11 and CSS4 fundamentals as they affect your bleeding-edge designs and device support.
  • Must be a member of the TC39, WHATWG, W3C, or CSS Working Group. Multiple memberships preferred. (Codepen.io account may be considered as a substitute.)
  • Experience with a variety of information architecture patterns and adept at articulating trade-offs and identifying the canonically correct approach based on bleeding-edge design trend biases.
  • 2000+ hours of remote user research testing experience.
  • Advanced comprehension of the general linear model, singular value decomposition, and chi square of eigenvectors as they relate to Map-Reducing real-user metrics into pie charts to demonstrate rigorous research findings.
  • Proficient at developing consummate visual concepts for web, mobile web, mobile apps, native iOS apps, native Android apps, Blackberry/RIM-platform emails, email, social media, social apps, social email, social games, micro-blogs, native desktop apps, and mainframe CLIs.
  • Ph.D. in Photoshop, Illustrator, Pixelmator, OmniGraffle, GIMP, TuxPaint, or Lightroom.
  • The ability to multitask and collaborate with a distributed, multi-continent, multi-timezone, multi-language cross-functional team under very tight deadlines while maintaining a sustainable Agile pace and positive attitude.
  • DevOps experience a plus!
  • Anal-retentive attention to minute details that borders on the DSM IV’s definition for obsessive-compulsive disorder.
  • Overwhelming desire to provide customers with designs that are at least adequately usable.
  • High comfort-level with frequent organizational pivots.
  • Excellent written and verbal communication skills. (Team members expected to write one novel or auto-biography every year!)
  • Advanced knowledge of HTML & CSS preprocessors (e.g., Jade, LESS, SASS, Stylus, Hamlet/Cassius/Lucius/Julius).
  • MS in Computer Science. (MA acceptable but we’ll need to talk about it.)
  • MFA in Graphic Design. (BA acceptable but portfolio must be killer!)
  • Ability to create award-winning user interfaces (UI) in-browser (more responsive mobile-first CSS3, less static images with text in them).
  • No fewer than 5 blog posts explaining monads. (At least one must have reached #1 on HackerNews.)
  • Must maintain at least 2 blogs.
  • Must have greater than 1000 Twitter followers.
  • Must have at least ten Dribbbles with 100+ fan heart favorite thingies.
  • Bonus points for growth-hacking experience!!
  • Strong JavaScript skills. (Must be able to explain closures in 5 seconds or fewer.)
  • Unicorn horn must extend minimum of 18 inches and be inlaid with gold.
  • Sophisticated knowledge of version control management (Git).
  • Can turn lead into gold. (Interview portion will test skills in alchemy.)
  • Eyes must be one-way mirrors.
  • Must be a good kisser.
  • Only Nobel Prize Winners considered.

If this sounds like you then click Apply Now below!

re: “Why Scrum Should Basically Just Die In A Fire”

by !undefined

RE: Why Scrum Should Basically Just Die In A Fire by Giles Bowkett.

I was resisting the urge to post anything beyond my remarks on Prismatic, but this made enough of the rounds among my circle that I felt compelled to chime in with a couple of follow-up thoughts.

First: we know that Bowkett is smart; we also know that has a tendency toward writing in a deliberately inflammatory or provocative fashion. Given the latter point, I would just chalk this post up to being another “conversation starter” (at best) or else (at worst) the tech-worker equivalent of clickbait.

Continue reading →