JavaScript is NOT a functional language

This humorous tweet garnered a plenty of attention early last week, and I confess I contributed to the virus with my own retweet. While I’m inclined to concur with the sentiment, I’m not completely comfortable doing so. To chose a side in the discussion implies not only that functional programming is a well-defined paradigm, but also that it is a Boolean property of languages. I’m not so sure we’ve all agreed what functional programming is, nor can we say that a language wholly is or isn’t functional.

My stance is the statement is neither true nor false, at least in the way it was meant to be interpreted. I certainly agree that JavaScript is more functional than, say, Java (especially prior to version 8), but it is also much less functional than the golden standard Haskell. Notice that I am making comparisons of the languages relative to one another, rather than partitioning the languages into opposing camps. I personally believe this is the best way to view a language’s place in functional programming as a position along continuum with imperative on one end and functional on the other.

On one end we have languages which we all agree aren’t functional, such as Small Talk or Pascal. The other end of the spectrum features the heralded functional language greats Lisp, Erlang, Haskell, ML, etc. What I find interesting is what lies in the space between those two. Some languages have properties which are certainly characteristic of the functional languages, but the language itself isn’t typically regarded as functional. Languages like Java are adopting features of functional languages making itself more functional. At what point does a language cross this mystical threshold?

Not only do I believe this should be regarded as a continuum, I believe there is a better question to ask when judging where the language lies: How much does this language help me write in a functional programming style? Let’s face it, Java will fight you to the death if you want to be functional, but the advent of lambdas and powerful libraries like Google’s Guava allow you to be quite a bit more functional than classic OOP Java.

What properties help us write in a functional style? A few that immediately come to my mind are (1) treating functions as first-class citizens, (2) declarative constructs, (3) bias towards immutable data, and (4) control over side-effects. This is by no means meant to be exhaustive, but properties like these ultimately combine to allow programs to achieve referential transparency, which is arguably the most important property of a functional program. This allows the developer(s) to reason about the program. The more a language favors these patterns as the idiomatic approaches to programming, the further towards functional programming end of the spectrum we should regard it.

Back to JavaScript, which is the title of this post. It does very well in the first property I feel we need, which is treating functions as first class citizens. However, it fails miserably on the next three. Many languages like Java at least give us a final key word, but everything is mutable in JavaScript. That’s not to say that you cannot write a program which does not mutate the data. It just means the language is not on your side to help you accomplish that goal. Hence, it makes sense to write an outstanding book like Michael Fogus did with Functional JavaScript. Yet the reader should be aware that it will take much discipline to retain the ultimate goal of referential transparency.

Another thing to notice is how some languages need libraries to allow the developer to write in a more functional style. I already mentioned Guava for Java. The Functional JavaScript book utilizes underscore.js. This shows me that sometimes a language needs a little help to be functional, but it can be done.

Perhaps also of interest is how much a language will allow you to NOT be functional. For instance, Scala is widely regarded as a functional language. Yet you can write some very filthy imperative code thanks to var declarations and easy-to-reach side-effecting calls such as println. Compare that to Haskell which requires you to rope off the entire function with caution tape like a crime scene to allow an I/O operation to occur. Hence, we could use this to say that Haskell helps developers write more functional code than Scala.

So I guess I agree that JavaScript isn’t a functional language, but only in the spirit that I don’t think it makes a lot of sense to declare languages as such, one way or the other. Rather we should make statements like “JavaScript helps me write in a functional style more than Java, but not as much as CoffeeScript which allows me write with more declarative expressions.” Even my most recent post has me regarding my ideal language as being functional. However, I think from now on I’m going to adopt the verbiage of stating how much I believe a language helps me write functional-style programs. I suspect this mentality will be more useful for discussing programming languages. It strikes me as being a little more objective therefore less likely to spark passionate-yet-pointless arguments about language design.

Leave a reply below, or send me a tweet.

Tagged with: , , , , ,
Posted in Software Development

If I were writing a language

I’ve never honestly put thought into what I would want in my own language until recently. For years I wore blinders while working contently in the world of Java. However my shift to Scala and full-stack development over the last two years has exposed me to a little of the world outside. I doubt I’ll soon find time to dabble with language design. But if I did, here are the features, concerns, and priorities I’d pursue.


My language would be functional, of course. I don’t know that I would attempt the OO hybrid that Scala has going on. Polymorphism indeed has its problems and I don’t want to deal with those. Clojure’s ad-hoc polymorphism is very intriguing, and I just don’t feel that data needs to be hidden. Functional is where the future is, and frankly it’s how I like to code.

Static typing

Yeah, duh. If you follow me at all, you know how I feel on this topic. I’m curious if this makes the language more difficult to design and implement. It seems obvious that it would given that it’s one more responsibility of the language. On the other hand, perhaps those guarantees buys some nice properties further down the line. Regardless, I’d like my resulting language to have the fantastic properties afforded by static typing. Seeing it done well in Scala and taken to the next level in Haskell makes me believe it’s well worth the cost.

Compilation targets

If I’m gonna write a language (and I probably won’t) I would shoot the moon. There is no silver bullet in software, but I wouldn’t let that stop me from trying to write the language to rule them all. In my web-oriented mindset, this implies compilation to multiple targets so it can be used anywhere. First, I’d target the JVM. It is a very impressive piece of engineering and would open up many platforms. In particular, it would be viable as a backend language and as a mobile language on Android. The second compilation target would of course be JavaScript. I’m still not a huge proponent of JS compilation, but the idea of compiling to a limited and optimized subset of JS is attractive. Although JavaScript has it’s good parts, it is absolutely riddled with filth. Frankly, there is no getting away from it in our browser world. I would also be keen on compiling to some native, perhaps LLVM would suffice. Ultimately, I just want it to compile to something which can run on iOS. Then all of the bases would be covered.


In keeping with the previous section, my language would need to be web-ready to every extent possible. Compilation targets of the JVM, JavaScript, and LLVM are for web-readiness. The trickiest part will the the FFI, of course. I think I would prioritize great FFI with JavaScript/JSON. I know it runs against the static typing grain, but I really dig the simplicity of JavaScript objects. They’re all just a map. What I want is a way to be type safe, yet be able to utilize JavaScript objects with a native feel. I really don’t know how this would pan out. What I want to avoid is what we have in Scala, where we have case classes for our server-side data, then (assuming Lift) we have our JsonAST objects and the translations in between. What I imagine is something like all objects having a constructor which takes a JSON and instantiates the class. How do I reconcile that with static typing? No clue. Perhaps JSON-ready objects would be a special case of object. I’d have to play with it.

Also for FFI and interoperability, I would definitely make those calls safe. Scala’s interop with Java is super smooth and easy, but it leaves much to be desired by letting all of Java’s exceptions and nulls leak in. In my language, any calls to Java or JavaScript APIs would be wrapped in a monad like Lift’s Box which can be Empty (analogous to Scala’s None), Error, or Full[A] containing the result you hoped for (analogous to Scala’s Some).

Is Purescript close enough?

Perhaps so. I’ve been intrigued by Purescript lately, but have not committed any time to try it. It is strongly, statically typed and influenced by Haskell, so I know it’ll hit my first two items. It compiles to Javascript, and understand that the semantics are close to JavaScript. I’m optimistic that the FFI would be pretty good in that case. I’m not the first interested in a JVM compilation target either. I stay pretty busy in my free time as it is, and I’ve only made it worse by recently becoming a Lift committer and writing articles for NFJS Magazine. I’ve at least taken the first step and purchased PureScript by Example by Phil Freeman.

Those are a few quick things I would consider anyway. Most everything else about a language such as syntax and such isn’t that important to me. I just need these couple of things to build what I like building. What about you? What would you want in your own language? Or what languages do you think come close to what I already have in mind?

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , , , ,
Posted in Software Development

On naming

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

At work a teammate and I have a long running joke about how we disagree with identifier naming. He favors long “descriptive” names, and I like short terse names. We never get angry over this disparity in our views, and mostly find good compromises during code review. As long as I’m not working alone, I’m more than willing to lay aside my preferences for the greater good of the team. Yet these past few days, my bias towards shorter names has been triggered into some passionate responses.

The most notable was a recent podcast from Functional Geekery featuring an interview with Adi Bolboaca. In this episode, Adi is discussing his experiences leading code retreats with host Steven Proctor. I really got worked up when Adi was speaking of how he battles functional programmers and their short naming. His claim is that descriptive naming was a principle of clean code which transcends paradigms. I just really felt that he got that one wrong.

But why? Why I do I feel strongly about using shorter names? I’ve put some thought into it and I’ve identified a few factors. Firstly I was a math geek before a software geek. I’m not talking about that math minor they forced you to get with your CS degree where you’re playing the role of the computer and not the mathematician. I’m talking about the “advanced” mathematics courses where the focus is on clearly communicating abstractions. I can’t quite recall names longer than a single character in my math courses. We’d rather reach into the bag of Greek letters to retain the brevity. If a second letter is introduced, it is as a suffix to indicate something else significant. Not a character is wasted. The reader is expected to apply the short names to abstract concepts and roll with it.

Fast-forward to the present where I am now engrossed with functional programming. This paradigm is far more closely related to the discipline of mathematics than traditional imperative programming techniques and theory (if any such thing exists). Given that functional programming is much more like math lends credence to my feeling that “clean code” applied to functional programming doesn’t carry long identifier names with it. Terseness is part of the paradigm. One can even argue that long variable names are an anti-pattern. I think it’s just the unfamiliarity of our Reverse Hungarian notation that led Adi to believe the principle still applies.

However, I feel I can lay aside the relationship to mathematics and it’s use of terse naming in route to understanding the underlying reason for my preference of short names. It all goes back to my attitude towards commenting code. The computer doesn’t care what you name things. The names we use are of importance to human reader of the code. They’re glorified comments. Names which are public and hence get included as part of an API and its respective documentation are certainly important and should carry meaning. Names which are internal to the code are mere comments attached to code artifacts. As I stated previously, I agree that the only useful comment is one that answers the question Why?. The name of an identifier never answers Why?. Rather, it always answers What? and often the context of the code has already answered this question, rendering the name redundant.

Perhaps the most classic example is the good ol’ loop iterator i:

for(int i=0; i<=10; i++) {

Developers worth their salt never use a verbose name like index for an iterating index such as this. The context and structure of the code already tell us that this is an index. By having the shorter name, the operative properties are more pronounced in the construct. That is, the start value 0, the stop condition <=10, and the increment expression i++ are quickly and easily identifiable. Longer names such as index, currentIndex, or indexOfTheLoop clutter this up and distract from these three vital pieces of information. Given that these three dictate what the code actually means versus what the author of the code thinks it should mean, I’m strongly inclined to prefer the more concise version.

In fact, functional languages like Scala take this even further. This construct is so common, we don’t even need as much clutter as the simple example above gives us. We compress it down further to the following.

for { i <- 1 to 10 } {

We see that the most important information in this construct is even more prominent: the start value 1 and the stop value 10. Incrementing by 1 is so common, it’s assumed unless you tell it otherwise. Don’t confuse this for more of my Scala evangelism for the Java oppressed. I’m pointing out that the functional paradigm’s embrace of terseness behooves us to reconsider what is regarded as clean code. I believe this results in those who have not adopted this paradigm erroneously believing the best practices transcend. The principles certainly transcend, with code readability being the principle in this discussion, but not necessarily the principles. I’ll go even further and argue that shorter names works well for imperative programming too, just as the for loop above suggests.

So what are my underlying principles with naming?

  • I believe that name length should be roughly proportional to scope size. The i in the above examples is a good specimen of a name with a tiny scope, and hence a tiny length is appropriate.
  • The name length should be inversely proportional to its frequency of use. A name that is repeated constantly through code needs to be short lest we introduce an epidemic of carpal tunnel. A frequently used name even if terse will be well understood. A great example of this is Lift’s S.
  • Don’t repeat the construct in the name. This is why we needn’t include “index” in the above name, neither should “accumulator” be used in a fold or reduce expression.
  • Don’t clutter the name with the context of the name. If you have a class named BankAccount, don’t use accountBalance. “Account” is already there, just let it be balance. Or if you have an actor, don’t name it’s internal state as currentState unless you are distinguishing it from other states such as previousState. Just let it be state.

Chances are good that I’m wrong that longer names are detrimental to readability. At least that was the consensus on twitter. If you take nothing else away from this post, let’s at least agree that longer isn’t always better.

Leave a reply below, or send me a tweet.

Tagged with: , , , ,
Posted in Software Development

ÜberConf Days 3 & 4: Hits and Misses

The last two days I hit some great sessions and some blah sessions. As I mentioned in my last post, my favorite part about this conference has been the people I’ve met and not the sessions as much. The third day I really saw that it can be tricky because although you can respectfully bail within the first five minutes of the presentation, I haven’t been able to decide if it is a miss until I’m in too far to make a switch.

Fortunately the day started off awesome with Matt Stine applying Uncle Bob Martin and Michael Feather‘s SOLID OOP principles to functional programming. As Matt pointed out, principles are universally true, and hence there should be no reason we cannot apply SOLID to functional programming. He did a fantastic job of demonstrating these principles with some Clojure code that I was able to mostly understand. The coolest part of this presentation was towards the end when he brought up the notorious Simple Made Easy keynote by the venerable Rich Hickey, and defined each of the SOLID principles in terms of complecting stuff that should be separate.

After such an outstanding talk, I thought I’d hang around and enjoy Matt’s next talk, Programming with Immutability. I should have read the overview/slides before this one started because it was all Java. Granted I still enjoyed the topic, I probably could have found something more relevant for me. Once he got into some details of different libraries to aid Java developers in adopting more immutability, I caught a severe case of disinterest and worked on yesterday’s blog post.

The next talk I attended was another dose of Nate Schutta titled You’re an architect… Now what?. I thought this would be a good one given my previous experience with Nate and my still-recent entry into the world of architecting. I came out of this talk quite reassured about how I’ve been approaching my opportunity.

After lunch I caught Rob Spieldenner showing off some of Netflix’s cloud goods. As much as I really enjoyed hanging out with Rob and Dan Woods from Netflix, this was not the talk for me. In a nutshell, it was a workshop on AWS using stuff that Netflix built because they don’t use Elastic Beanstalk. Although Rob did a fine job with the workshop, it just brought me back to how much I don’t enjoy the AWS aspects of my job.

I had no qualms skipping the second half of the AWS action for some scaling agile action with Esther Derby. This talk was probably better than I realized, but the exhaustion of the conference was building quite strongly by this point. I wasn’t able to focus very well, although I did live tweet a handful of good nuggets. Other than my general interest in agility, my primary motivation for attending this talk is to be prepared for when my team grows or our project gets other teams working on the code base. The problems we have at our tiny size will be very different from the ones we’ll have when (not if) those things happen. The biggest point that resonates with me is her suggestion to not divide teams up by component/function. Each team should be full-stack and able to deliver working pieces of functionality without depending on another team for the rest of the vertical slice. Beyond that I mostly came away with more reinforcements for what I’m already learning at work and through other resources such as This Agile Life.

I started the next day watching Rob talk more about Netflix, but this time it was about continuous delivery. Although I like where my team is on this front, I know we could get better. One of the most interesting things I discovered is that they don’t just deploy application code like we do. Their teams build out (or “bake” as they like to call it) the application code along with a machine image which eventually gets dropped and deployed on the cloud. I also learned that there are a lot of monkeys running around their cloud. The have scripts they’ve given monkey names that randomly kill off machine instances in production, in addition to scheduled drops of availability zones and regions.

Next up was some JavaScript patterns with Raju who I’ve found is yet another fantastic No Fluff presenter. Even though we use CoffeeScript at work for all of our JavaScript, I expected much of the patterns to translate. I came home with some new tricks of my sleeve. Unfortunately as you can guess, most of what he showed was things to keep you from dying in the wild world of JavaScript, many of which are handled for us in Coffee.

And then, there was Venkat. I must say that the schedule set up to save the best for last. I hung out with most of the speakers at the conference, and every single one of them would back me up when I say that Venkat is a rock star developer, teacher, presenter, anything software. This first presentation of his that I attended was on Nashorn, the JVM JavaScript engine which ships with Java 8. Although I left the talk still not sure how I should use JS on the server, I learned that it is a well-designed/smooth tool in the JVM tool belt. The FFI interop with Java is very impressive. I also found it quite interesting that it actually has a “script mode” which gives you a handful more tricks to use in your JavaScript. I also didn’t know that it is packaged as an executable with the JVM so that you can get a REPL or pass it a JS file to execute. As a result, you can shebang the top of your JS scripts and now you have executable scripts like any other. The sickest feature I saw was how you can define a Java interface to match the functions you have in your JS, and on the fly it will provide an instantiation of that interface which is wired up to the underlying JS. As I’ve said before, I’m particularly excited to see the JVM really embracing its emerging role as a polyglot runtime environment. Overall very cool stuff, very well presented.

And then, there was Venkat on Haskell. Finally, I sat down and learned me a Haskell for great good. Over my career, I’ve learned that there is only one way that I really uptake another language. That is, I have to watch someone walk me through the first steps. Until that happens, I’m all talk. I learned C, C++, and Java at my university (yeah, notice the embarrassing lack of functional languages there? I’m still nudging them over that problem). I picked up Scala from Martin Odersky’s free online course. Dave Lee exposed me to CoffeeScript while presenting a JS library at HuntFunc. I picked up Clojure earlier in the conference, and now Haskell. The two exceptions to this is JavaScript (necessity and deceptive ease) and Groovy (as a super-set language, I didn’t need to learn much to get started). I believe the biggest thing that slows me down from starting a new language is the fear of how much time I will invest before realizing any productive gains. For some reason in my mind, I feel I’ll get over that hump more quickly if there is someone showing it to me. Anyway, I digress. On to Haskell.

Haskell is every bit of bad ass I expected. I was pretty comfortable with many of the concepts because of my work in Scala. As much as I love type inference in Scala, I didn’t realize how much I was missing. Haskell will look at the body of the function and infer output AND input types. I’ve been doing Java and Scala so long, that it hadn’t even occurred to me that such a thing could happen. I really love the ideas behind having an IO monad and all that good stuff, and it was cool seeing it in action. One thing I didn’t expect to see is how the inputs to a function can be pattern matched right there at declaration time, reminding me of what I’ve seen in Erlang. I also had forgotten how every function in Haskell takes at most one argument. More arguments just means that you’re really returning another function with the next argument. Unfortunately, I’m in the same place with Haskell as Clojure… I don’t know what I should aim for next. I need to dream up something I can build with each one.

So that was the rest of the sessions I attended. As I’ve said many times, the best part is the stuff I’m not bothering to write up: Hanging out with other developers. Although I enjoyed a lot of talks at this conference, I would gladly return only to hang out. I’ve made some great connections that I’m excited about and I look forward to what some of us might be cooking up in the near future. Stay tuned.

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , ,
Posted in Software Development

ÜberConf Day 2: Second expojure to Clojure

Day 2 for me at ÜberConf was the first day for many, as it marks the beginning of the meat of the conference. I didn’t love the first two sessions, but they lived up to my 3 of 5 stoke rating. While Kirk Knoernschild did a fine job presenting the modular architectures material, it wasn’t anything new to me. The refactorings he demonstrated to obtain a modular architecture to the code base just seemed obvious to me. I’m a fan of OSGi, although I don’t use it on any current projects. Hence I left that one quite underwhelmed.

For the second talk, I really took a liking to Nate Schutta. The topic of leading technical change described many behaviors I already exercise to stay abreast with the developments in our craft, such as reading blogs in down time, turning off the TV, etc. I thought the talk would be more about how to influence change in our organizations (although that piece was there a little bit). Despite all of that, I just thoroughly enjoyed Nate’s presentation style and the great points he made throughout. A great example of the sorts of things he said came out in an earlier talk I didn’t attend when he almost quoted Jason Tice from This Agile Life by stating “We’re not FTEs. We’re not ‘resources’. We are people. Treat people like people.” Needless to say, I shared that podcast episode with him.

(EDIT: In the original post, I completely forgot this talk)
The third talk I joined covered the Java type system. I don’t feel like getting much into it, but I came away realizing how much of a train wreck it is. Not trying to be arrogant here, but it really is a pain, especially with mutability ruining everything. Great talk, but the material was a little depressing if I think about having to go back to Java.

On to the second half of the day, the more compelling half of the day… As I’ve mentioned before on this blog, Clojure was the first functional language on the JVM I looked at. In that post I also expressed a renewed interest in Clojure, and now a little over a year later I finally took initiative and dove in. And when I say “dove in”, I mean I got violently barraged with Clojure. Neal Ford does not mess around when leading a Clojure workshop. He and Stuart Holloway made a conscious decision to make their intro to Clojure try to cover EVERYTHING and see what sticks with the audience. Firstly, I LOVED this approach. I always hated the snail pace of school… Like yeah, I got it the first time. Granted I didn’t understand half of what he showed, but the half I did understand is far greater than the quarter of the material I would have comprehended if given at a slower pace. So kudos for that.

I would have sunk in this workshop two years ago. I don’t know how any Java developers swam in those two sessions. If it wasn’t from the comfort level I’ve already built up for immutability, persistent data structures, code compactness, etc; there is no way I would have comprehended anything beyond "Hello, World!". I know, because I tried it before. I got to the REPL, entered (+ 1 2 3) enjoyed the echo of 6 and didn’t know what to do next. I think I’m actually ready to play in Clojure more now. I feel really torn tho because I am enjoying Scala so much at the current time, both at work and in free time.

So I thoroughly enjoyed this workshop, and I think I made a good decision forgoing my original plan to attend two JavaScript sessions. It also prepped me to be more comfortable with Matt Stine‘s use of Clojure in his Functional SOLID session. (EDIT: I’m a little ahead of myself here, as this talk occurred day 3) I’m starting to feel a LOT of pressure to spend more time in Clojure. I’ve noticed the Clojurians often point out the complexity of Scala’s syntax. Given how elegantly simple Clojure’s syntax is, I see where they’re coming from. Everything is just a list. '(1 2 3) is a list, (+ 1 2 3) is a list. A record is just a map, and it receives the benefits of all of the map functions. Scala on the other hand is frankly more like Java; there are these special things and those special things, etc. More so than ever before, I understand why Scala is often regarded as “just a better Java”. As I listen to some of these guys talk about the differences, there is a part of me that can’t stop thinking about some of the good points made.

And on that point, even if I were swept off my feet by Clojure, I still believe I made the best choice to set my team on our current course with Scala, Lift, Akka, etc. The tooling available for web application development is much more mature; Lift being the most outstanding web framework I’ve yet to experience. More importantly, I believe my team needs a gradual adoption of functional programming. There is no way I could have shut our shop down for a month while we learned a new language in hopes that we would catch up later. We needed to maintain productivity using our Neanderthal OOP skill set while we foster our still-budding functional programming skill set.

Yet a danger lies there. After the workshop, Neal and I had a great conversation about the merits of each Scala and Clojure. He described the situation as if we are standing in the OO/Java world looking at the distant functional programming world. Scala paves a wide parking lot across that chasm, allowing us to leisurely take our time reaching the functional programming world. Unfortunately, you can easily become complacent in the journey and set up camp somewhere short of functional programming. Clojure on the other hand is a narrow bridge straight to the FP world with no middle ground.

That last statement is arguably my greatest attraction to Clojure, with its elegant simplicity standing right behind it in second. Having been increasingly immersed in Scala over the past two years, I am now sold on functional programming. Now that it is clicking, I am done with the imperative paradigm. I crave referential transparency, which is arguably the greatest advantage of functional programming. I want immutability, and I want to tightly constrain side effects. I would love to spend more time in a more purely-functional language to see if I can finally defeat the last remaining footholds of imperative and object-oriented thinking.

I’m still a wee bit hung up on the dynamic typing. It won’t stop me from playing with Clojure, as I’d argue it is the most compelling functional programming language on the JVM (here, I don’t say Scala as it is a multi-paradigm language). I just think it is too valuable, throwing out the baby with the bathwater sort of thing. While I was talking to Neal, he said he felt that while static typing is valuable, it isn’t worth the cost. Matt shared a similar sentiment, lamenting that he quickly tired of fighting the compiler to run code that he knew would work. I’d like to see an example of this. In my experience, it didn’t compile because it was wrong. He even joked later on that in Haskell, if you can get it to compile then it works. Given how much Scala attempts to borrow from Haskell, this can hold true for it in many cases too. All of that aside, I see where static typing may not be appropriate for Clojure. It seems a bit dynamic in the way it likes to treat records as a map, and nearly everything else as a list.

So what’s next? I need to spend more time with the exercises Neal sent us home with. From there I need to find something to work on in order for me to stay motivated. As much as I love code, I only do well when there is a goal involved, particularly something to be built. I did receive a tweet inviting me to help with an OSS MongoDB driver wrapper. While that is moderately interesting, I’d love some other suggestions.

As if this wasn’t a long enough day, I wrapped it up by attending a make-up AngularJS workshop from Raju Gandhi. Even though we already use Angular at work, I was optimistic that I would learn some things that I’ve missed along the way. The main thing I came away with is a better understanding of how directives and such work. The best part of this one was meeting Raju and picking his brain on some of our developments with lift-ng.

I closed the day out by hanging out at the bar where I was fortunate to find many of the speakers and No Fluff Just Stuff organizers hanging out. I spent a lot of time talking to their lead developer (drawing a blank on his name at the moment). I’m certainly experiencing what others have told me about conferences: The sessions and keynotes are great, but the people you meet are the greatest part of the experience.

Leave a reply below, or send me a tweet.

Tagged with: , , , ,
Posted in Software Development

ÜberConf Day 1: Web Application Security Workshop with Ken Sipe

Day one of ÜberConf was the workshop day, and I attended the Web Application Security Workshop with Ken Sipe. I’d say the workshop met my expectations. There were parts that I knew, parts I didn’t know, that sort of thing. Here are a few hits that stood out.

This is something I had never really thought of. Single sign on? Convenient! Great user experience! But it is a security vulnerability no matter how well implemented. Another example he gave that really stood out is Here you give them your banking credentials, and it grabs all of your transactions and helps you budget, etc. Great user experience, but now you’re credentials are stored out there.

In other words, think of security up front. This is often one of the last considerations given to an application, but it’s arguably too little too late. It left me with the impression that I should really bake security into an application. This makes sense because when you have the hood up on a feature, that’s when you are thinking about all of the paths and use cases. While you’re there, go ahead and think about how it can be abused.

Another observation I’ve made during this workshop is the power of two. What I mean is having two different security measures. The one we are most familiar with is 2-step verification, where after logging in with valid credentials, the web application sends you a text message with a token/id. The principle in play is the unlikelihood that someone has stolen both your credentials and your phone, or hacked both systems perhaps. Another example of this I’ve not thought of before is the unlikelihood a malicious individual has gained access to both your application data and your application source. For instance, if you hope to not repeat the LinkedIn mistake, you should salt your passwords. We could use some immutable data about each user (such as the account creation date) and apply some application-level logic to it (convert it to millis, then compute the modulo with a big ass prime number) to create the salt. Hence to unlock the hash, you need both the data and the source to know how to compute the salt with the data.

As with anything in software, there is always a cost/benefit to consider. Ken highlighted how this also applies to your threat analysis. Perhaps you have identified a vulnerability in your system. Before you address it, you should first consider the likelihood of exploitation and the cost of that exploitation. An example he gave was related to his work on GoGo internet which serves in-flight wireless internet services. The pool of potential attackers have all paid a large sum of money for a plane ticket, and they are in the network for a relatively short amount of time. Hence, the need to make sure the service isn’t stolen or somehow discounted is probably not something of great value that the development team should invest time into.

So far so good at ÜberConf. I have no idea if I’ll write any more blog posts while here. Frankly I got bored during the exercises and blogged up what I learned today. I doubt that will happen for the remainder of the event.

Tagged with: , , ,
Posted in Software Development

Picking ÜberConf sessions sucks

I’m gearing up for ÜberConf next week in Denver. It will be my first tech conference. I’ve never gone because I’m cheap and would like my employer to pay for it. I’m very grateful to Mentor Graphics for their willingness to invest back into me by sending me to a conference this year. Now that it’s days away, I have to go through the sessions and decide which ones I will attend. There are so many good sessions that are run concurrently, causing me to find this process pretty frustrating.

When I first looked at the conference and the sessions planned a few months ago, I had in mind that I would learn some Clojure, R, Java 8 lambdas, and more agility skills. Due to changes in the sessions and changes in what I’m working on, I will be attending zero sessions on those. I’m not using Java at all now days. I’m curious about R, but it’s not particularly relevant to me. I would LOVE to learn some Clojure, but there are some killer JavaScript sessions at the same time which I know I need for my daily work. I suck at JavaScript and any help will be greatly appreciated. I really want to brush shoulders with more folks doing agile, but dang it if every one of those sessions doesn’t coincide with a more technically interesting one. As much as the guys at ThisAgileLife have me excited about being an agile developer, I still feel the strongest draw to the code itself.

So here are the sessions I plan to attend, why I picked them, and why the others didn’t make the cut. Click here for the complete list of available sessions. Not only are these subject to change, there’s a chance I’ll skip a session altogether if I’ve run into someone more interesting than the topics to choose from.

Session #7: Web Application Security Workshop by Ken Sipe

The first day of sessions are full-day workshops that are an extra charge. I figured since I’d already be travelling to Denver for the event, I might as well attend all that I can while there. Picking this session wasn’t too difficult. Of the things I really don’t have a great grasp on, security is probably the one that I need the most. I generally rely on frameworks and libraries to be awesome in the security department by default like Lift is, but that won’t always be good enough.

Stoked? 3 of 5
Let’s face it… I’m not excited about security, I just know it’s something I need.

The runner-ups:
Session #1: Angular Workshop by Raju Gandhi

I would love to learn more about my favorite JavaScript library/framework, but I suspect this one will be too introductory-level for me to gain a lot of skills.

Session #5: Building Modular Architectures by Kirk Knoernschild

This was my second choice, but I have other opportunities to hear from Kirk regarding modularization during the conference. No such second chances exist for security.

Session #15: Modular Java Architecture by Kirk Knoernschild

I’m always interested in busting up big things. Big stories into smaller stories, big chunks of code into smaller ones, and certainly big applications into small configurable modules. Although this one has that antiquated language in the title, I’m sure it’ll still be applicable to this Scala slinger.

Stoked? 3 of 5
I’m cocky enough to think I can already do this well enough, but wise enough to know I don’t know half of it.

The runner-up:
Session #12: JavaScript Workshop, part I by Pratik Patel

This being my only other options made my choice easier. I suspect this one will be too introductory for my JavaScript skills, despite being admittedly sketchy.

Session #30: Leading Technical Change by Nate Schutta

As someone who has twice attempted Scala adoption, this one really jives with me. I figure most people in this session are entering a little frustrated that they’ve not succeeded in adopting a technology they like. I’m hopeful I’ll leave better equipped to continue leading these types of rebellions, and encourage the other attenders along the way.

Stoked? 3 of 5
Been there done that, but I’m pretty passionate on the topic.

The runner-up:
Session #25: Toward Agile Architecture by Kirk Knoernschild

There is a good chance I’ll still go to this one, depending on how much I enjoy his prior session.

Session #37: What’s in a Type? A Mathematical View of the Java Type System by Douglas Hawkins

In case you haven’t noticed, I’m interested in type programming. If this was the Scala type system, I’d be stoked off the chart. The Java type system will do. After all, Martin Odersky was pivotal in developing the Java 1.5 generics, and I figure I can pick this guy’s brain on more advanced type systems.

Stoked? 4 of 5
Loss of a point for being about Java.

The runner-ups:
Session #31: Continuous Delivery for Architects by Neal Ford

I would certainly enjoy learning more here, but I feel my team is in a pretty good place here.

Session #38: Guava for Java by James Harmon

If I could foresee any future Java development for myself, I’d be all over this.

Session #40 : Becoming More Agile by Ken Sipe

I would love to talk some agile, but math wins.

Session #44: Functional JavaScript by Pratik Patel

There should be no surprise in my interest here. I’d love to be better at using functional programming in a language I spend a lot of time in. Granted we use CoffeeScript, it is so semantically similar that I’m certain all of the skills will translate.

Stoked? 5 of 5
Nearly lost a point due to conflicting with the first runner-up…

The runner-ups:
Session #47: Introduction to Clojure Workshop Part 1 by Neal Ford

I’m so frustrated that this session coincides with Functional JavaScript! I’m equally excited about both topics, but I had to use the “I will actually use this at work” tie breaker to settle this one. My apologies go out to local Clojuremen Bret, Chad, and Eric.

Session #50: The Top Agile Pitfalls that Lead to Trouble by Andy Painter

I’d probably rate this one a 4 of 5, but dammit if it doesn’t coincide with two 5’s. I have to believe my team does half of the caveats given in this session.

Session #54: JavaScript Design Patterns by Pratik Patel

Back in my late undergrad days, OOP really started to click when I took a design patterns course featuring the infamous Gang-of-Four. I’m optimistic that some things will really start clicking for me in the wild world of JavaScript.

Stoked? 4 of 5
MOAR JAVASCRIPT!!! Well, not that I love JS but it’s a necessary evil that I’m currently living with.

The runner-ups:
Session #57: Introduction to Clojure Workshop Part 2 by Neal Ford

Why couldn’t this be the time slot for part 1??

Session #60: The Disciplined Agile Team by Andy Painter

I’m a huge fan of discipline, and teaching it. I would hope this session would leave me well-equipped to teach others more effectively. I doubt I need much more convincing.

Session #61: Understanding Garbage Collection by Douglas Hawkins

I’m basically picking this one because it’s the only one I’m really interested in during this block. It should be really interesting and relevant, especially given how Scala doesn’t like to mutate data. I’m sure I tax the GC a little more as a result.

Stoked? 3 of 5
If I were Michael Bernstein, this would be 5 of 5.

The runner-up:
Session #69: A Java Dev Learns to Go by Matt Stine

I’m only mildly interested in Go.

Session #77: Functional SOLID by Matt Stine

I spent the requisite 10,000 hours to claim mastery of object-oriented programming thanks to my years of experience in Java. Now it’s time to bolster my journey in functional programming with principles that I probably should have known when I started.

Stoked? 4 of 5
A topic featuring “functional” in the name gets a minimum of 4.

The runner-ups:
Session #71: Hacking Workshop by Ken Sipe

Who wouldn’t want to learn more about hacking?

Session #72: JVM Mechanics by Douglas Hawkins

This one enjoys a slight chance of increase in interest based on how the prior GC talk goes.

Session #73: The JavaScript Developer’s Toolchain Workshop by Nathaniel Schutta

I can’t help but believe that half the reason I suck at JavaScript is that I’m ill-equipped.

Session #87: Programming with Immutability by Matt Stine

I’m already quite used to this in Scala. I don’t remember the last time I needed a variable. However, I’m putting in a bet that I don’t know it all yet.

Stoked? 4 of 5
A topic featuring “immutability” in the name gets a minimum of 4.

The runner-ups:

Two continuations of sessions I’m already skipping for SOLID.

Session #100: Scala: Demystifying The Funky Stuff by Daniel Hinojosa

This session is supposed to cover several things I’m already competent in, but there are some that I’m not so comfortable with. I hope this will solidify my understanding of familiar areas and make sense out of the fuzzy ones.

Stoked? 5 of 5
It’s Scala. Did you even have to ask??

The runner-ups:
Session #91: You’re an Architect…Now What? by Nathaniel Schutta

I hate to miss this one as I a sit here completing my first year of legitimately being an architect. I just can’t skip a Scala session given how much time I spend slingin’ it.

Session #97: Kanban for the simple team or complex enterprise by Andy Painter

It pains me greatly to miss this one as well. I’ve threatened several times to urge our team to try it out for a few weeks. I feel that scrum is limiting us in some ways that Kanban would free us. However, I don’t have an idea of what we would lose.

Session #110: Testing In Scala by Daniel Hinojosa

For someone who loves TDD as much as I do, I don’t feel I’m anywhere close to mastering testing when I’m doing Scala. My biggest weakness is effective mocking. I’d also like to get a better handle on property-based testing. Hopefully both of these will be strengthened by this talk.

Stoked? 5 of 5
Scala and TDD for the win!

The runner-up:
Session #107: What Does Self-Organizing Team Really Mean? by Esther Derby

Anything agile-related is of interest, but it doesn’t trump Scala.

Session #111: Reactive Programming by Venkat Subramaniam

Finally, I get to see Venkat in action in person. I fell in love with this guy’s presentation style when I saw his Scala Tricks presentation on youtube. I’m already quite familiar with the topic at hand, but it’s quite the driving force behind a lot of what I develop.

Stoked? 4 of 5
Venkat on one of the hottest topics in development? Full of win.

The runner-ups:
Session #118: Introduction to Go by Ken Sipe

There is a slight chance I’ll switch to this one. I’ll get to see Venkat later, and it’s the only chance I’ll have to check out Go despite my lack of enthusiasm for it.

Session #120: Playing with the Play Framework by Daniel Hinojosa

I’ve already built a simple app with Play and Angular. Not only was that an underwhelming experience, I suspect this introduction will do little to show me more than I learned on my own.

Session #121: Rich Web Apps with Angular by Raju Gandhi

I’m on the fence about this one. I expect it to be too introductory for me, but I also bet there are some basic features I’m not utilizing. I just sorta jumped in with it and started building stuff.

Stoked? 3 of 5
I love Angular, but the likelihood being too introductory is killing my interest.

The runner-up:
Session #129: Continuous Delivery at Net#ix: Speed at Scale by Rob Spieldenner

Hmm… Now that I look over this one again, I feel I’ll probably switch. I like where my team is at on this topic, but I’d like to see how they’re doing it so well, especially with AWS. That’s the bit that has been the biggest hang-up for me.

Session #131: JavaScript Patterns by Raju Gandhi

Another dose of patterns in JavaScript? Sign me up!

Stoked? 4 of 5
Same as before. Different instructor, so hopefully that much more to learn.

The runner-ups:

None for this block.

Session #146: Exploring Nashorn by Venkat Subramaniam

I’m interested in Nashorn for a few reasons. I’m currently the owner of sbt-jasmine-plugin and it uses Rhino for JVM evaluation of JavaScript. Rhino has had a good run, but it hasn’t been touched in years. I’m also curious what are the other uses of JavaScript from the JVM.

Stoked? 4 of 5
Venkat rocks and I dig the idea of the JVM giving first-class citizenship to alternate languages.

The runner-ups:
Session #145: I have seen the top Akka mountain, and it is good. by Daniel Hinojosa

This one is much like my feelings on the reactive talk and the Angular talk. They’re all some of my favorite topics, but I fear I already am familiar enough to not glean much from an introductory talk.

Session #149: R : Workshop I by Brian Sletten

Out of one side of my mouth I preach getting exposed to the most number of languages possible. Out of the other side I don’t ever feel like I’ve got the time to invest in something I don’t feel I’ll use. So count me among the hypocrites.

Session #156: Haskell for Java Programmers by Venkat Subramaniam

Stoked? 5 of 5
This is by far the one I’m most looking forward to. I’m most excited about Venkat of all the speakers, and I really want to learn me a Haskell for great good.

The runner-ups:
Session #155: Making Java Bearable with Guava (2014 Edition) by Daniel Hinojosa

Given that Daniel is covering several Scala sessions, I’m more inclined to this edition of Guava talk. No way in heck I’m missing Haskell for it.

Session #159: R : Workshop II by Brian Sletten

If I don’t take the first R session, I certainly won’t waste my time here.

Thanks for processing these tough decisions with me. I can’t wait to get there! On one hand I’d love to drop a blog post every day highlighting what I’ve learned. On the other hand, I don’t need to miss any opportunities to hang out with the people I meet there. We’ll see…

Leave a reply below, or send me a tweet.

Tagged with: , , , , , , , , , , ,
Posted in Software Development

Get every new post delivered to your Inbox.

Join 569 other followers