This tumblog is dead-is-dead-is-dead
You’ll now find me at regretful.ly
Same infrequent posts, same lack of attention, same adoration of all impractical, but now with a newer, sadder name. Win win!
Decomposition through exposition towards eventual composition
Decomposition through exposition towards eventual composition
or
Why FP?
Why FP
-
Simple to reason about
- inputs yield outputs
- data and behavior are the same
-
Simple to decompose
- functions are truly first class
- when everything is composed of functions/data powerful patterns of abstraction become available
- currying
-
Simple to compose
- partial application | a function without all it’s arguments simply returns a function expecting those additional args
- (implicit in ML style languages, explicit in lisps/clojure)
-
Composition leads to reuse
- Almost anything you can imagine writing that’s a general operation, you will almost certainly see that it was available to you before hand.
- Learn to recognize patterns and be tickled by them, intuit that someone smarter than you has probably solved this.
-
Programming, motherfucker
- it matters
- …the more you know!
- exposure and experimentation build & refine tastes
- Do you have an argument for not knowing more? Is putting the shoe on the other foot a bad idea sometimes?
Why Clojure
-
Lightweight Syntax
- very little to learn, data and behavior share representation
- omg parens. Whatever, like everything about programming you currently understand made sense to you immediately.
- I can’t read arabic, so it’s fucking worthless?
-
Pragmatic
- Nearing two years old, it’s not just going to go away
- first class citizen of the JVM. There is a Java library for your problem, and it’s probably a lot more refined than you realize.
- ie: ruby has can reach out to C, but there’s almost no reason you would unless you really had to. It’s hard.
- performant… without the expense of obfuscation. Write code as succinct (if not more so), than your current code, and watch it fly
- people are using it on real projects to solve real problems
- Relevance
- 8th light
- Edgecase
- Atomic Object
- … and plenty of startups
- … and plenty of enterprise companies
-
Hype
- founded hype, at that. Solves real problems, unlike things such as Node.js (if evented concurrency was a good idea, tornado or eventmachine would be successful)
- a real chance to innovate and be thought leaders
- making a grand impact on the Ruby and Rails community is really hard right now.
- … but maybe if we listened to other communities more we could see what we’re lacking
- it’s a two-way street
-
Fun
- A lot of what attracted me to the Ruby community when I came into is present in the Clojure community
- Want to work with passionate and intelligent people?
- Attract talent! Recruiting is HARD, especially right now
- it’s just compounded with super smart JVM/Java guys
- and super smart Lisp guys
- and super smart CS guys
- and you don’t need to rewrite every tool ever. The ecosystem is already there.
- when you do need to rewrite a tool, guess what, you’re a hero. Well done.
- palpable excitement from the community. Haven’t felt that in a while here :(
-
Simplicity vs Ease
- Ruby is easy… sort of
- Clojure is hard(er)… sort of
- Ruby makes it really easy to get a reasonably tiny system up and running quickly, and achieve sorcery in the process
- Clojure (and FP in general) make it really easy to get reasonably large systems up and maintainable, and achieve wizardry
- A LOT of our apps go longer than 3-4 months. Perhaps we should think about things longer term.
OOP vs FP
This is a stupid slide, we can talk about it later.
Making it Real
-
Service Layer behind a Rails app
- we should probably be designing a lot more of our applications this way anyway
-
Full Stack
- the framework support isn’t quite there yet for getting up and running quickly
- …but most of our projects last longer than a month anyway
- and if it truly is tiny enough that it would be a month long project… then the tooling is there
-
During the times we’re not using Clojure, we will be better Ruby devs for having done so
- Learning.
- Learning.
- Learning.
- … Ruby supports (and took!) a lot of abstractions from Functional languages and Lisps
So why not?
-
Learning new things is hard
- You need to learn FP and Lisp in one swoop
- I had a hard time reasoning about CLJ in my independent studies without spending time with Haskell first
- There’s a good chance OOP has broken your brain.
- It’s not always easy to reason about problems in new ways
-
We are the next wave of BASIC programmers
- … that was a Dijkstra joke
- “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
-
As a Rubyist that learning curve is lower
- You understand type dynamism
- You understand metaprogramming
- You understand higher order functions
- Enummerable
- Blocks, Procs, Lambdas, Object#method
- You probably care about programming if you’re here
-
Tooling
- Especially around Vim, it’s not quite there yet.
- …but if you know how to use Vim outside of a Rails app anyway, you’ll be fine
- Pure Clojure Libraries
- A lot of them are missing
- Sometimes interacting with a Java library can be clunky
- If it becomes enough of a problem, write a wrapper around it. The Facilities for doing so are awesome.
-
Vulnerability
- You don’t know everything
- You need to admit and be in tune with this if you want to grow
- Making mistakes… probably more than you’re used to
- … but that’s okay
- I’m pretty sure you weren’t as bad ass as you are now when you first started with
- Ruby or…
- Objected Oriented Programming or…
- Abstractions or…
- Programming
Concrete, damn you!
- I don’t know (every|any)thing either.
-
This becomes more apparent to me every day
-
Let’s look at some code
The problem with blogging is blogging
There are two things that immediately strike me as problematic when trying to talk to you (dear reader audience), and those are as such: ego and confidence. Perhaps with more concision that could be said as solely confidence.
I need to feel good about what I’m saying to you personally, which I seldom do. I often reflect fondly upon things I’ve done or said or created in the past, but seldom at the moment (and the times I do, tend to be with crafts I’m more practiced in, writing not being one of them). So, here is an open effort to disregard that inkling of stfu that’s lurking back there.
Second, and more importantly (and perhaps encompassing the first) is confidence. I don’t know about you, but myself, as a student of all things and everything, am very seldom confident in… well, anything. Right? It would be foolish to be so. There are so many (brilliant) people out there, doing so many (brilliant) things, that are on levels that I can only begin to grasp, why should I think that anything I do is actually correct? (or even approaching being as such).
Perhaps the problem is even simpler than ego and confidence, it’s an issue of respect really. If you’re going to read what I’m putting forth here, it should be worth your time. When it’s something brief and obviously helpful (ie: found this in a google search, thanks bro!) then yes, I can justify breathing these words in front of you, when it’s me waxing philosophically about my current understanding of software (development), then it’s MUCH LESS OBVIOUSLY SO, to me.
From here on out I’m going to assume what I have to say matters with the hopes that one day it does. Sorry in the meantime, but I hope when we’re approaching the end of our journey you’ll forgive me (and that I’ve produced something of value to you).
TLDR: Fuck it, I need to brush up on my prose. (Also, wtf, c’mon, someone has to listen to me. You like hearing about monads from someone who doesn’t have a cs degree and hearing about life from someone who can’t figure it out, right?)
(ending with a statement in parens is pretty lacking in emphasis)
An exploration of the Maybe Monad in Ruby
A (perhaps crude) exploration of the Maybe Monad in Ruby.
I realize this is somewhat treaded turf, however it was done for my own learning, and I think came out pretty clean! Needs tests and could be made more flexible, yada yada.
Usage:
nil.maybe { |n| n + 2 + 3 }
=> nil
Which is essentially the same as nil.try(:+, 1).try(:+, 2).try(:+, 3) If the result is nil anywhere in the chain, the block simply returns nil
Object.antialias_method
I doubt I’d actually do this, but the pattern of defining a method, only to have it return the inverse of another method is common enough.
ie:
def unregistered? !registered end
But alas… stupid ruby things are fun.
So there.
Ruby Debug in Ruby 1.9.2
Currently, ruby-debug19 head is broken in ruby 1.9.2
in your Gemfile, have you happily debugging again.
Thanks to abuiles for finding this solution :)
Easy Parallelism in Ruby
Last week, @voxdolo and I were faced with a problem: our application needed to make 3 API calls at once, and while two of the services were ok (finishing in three seconds or so), the third would take up to 8 seconds to retrieve it’s data. When done synchronously this meant on a good day we’d get out in 14 seconds, which is simply unacceptable.
After deciding we didn’t want to manage threads ourselves, we discovered the excellent Peach library. Peach, which stands for parallel each, is an insert and go parallelized each (via [].peach) for arrays, not to mention map ([].pmap) and select ([].pselect). Simply replace the standard ruby method calls you need to be asynchronous with the peach equivalent, and you’re good to go.
In case you haven’t gotten it yet…
So while the name is only clever for the basic each, the lib is still awesome for quickly tackling async actions.
With a little UX love and the now 8 second data retrieval, we were able to make this workflow intuitive to the user (and less painful in development). Huzzah.
One caveat: In using this with MRI, you will see a slight decrease in speed of an individual process, however in our case, the gains have been dramatic.
Pair Program, all the fucking time.
(via @johnguenin)
Enumerable ! methods and Mongoid
One should be aware when using ! methods (slice!, map!, etc!) on the collections returned from Mongoid queries ie:
foos does not have foo1..3 shifted from the array as you’d expect, it’s state has not been mutated.
I’m not sure if this is by design or otherwise (it most certainly is a by-product of the lazily evaluated nature of Mongoid queries, but for the time being
foos = foos.to_a; foos.slice!(0,3)
will do the trick.
Just something to look out for!
Install RubyCocoa on RVM
I’ve been using RVM (and gemsets) to manage my Rubies lately, to much success.
I however ran into the issue today of trying to install rspactor (think autotest on ‘roids) which depends on RubyCocoa to monitor changes to the filesystem.
As it would turn out, when you vanilla install a Ruby via RVM, RubyCocoa is unsupported.
To enable installation of RubyCocoa you’ll need to set a few flags during Ruby installation:
rvm install 1.8.7 --debug --reconfigure -C --enable-shared=yes
Then you are able to configure and install RubyCocoa as usual
cd path/to/rubycocoa/src
ruby install.rb config --build-universal=yes
ruby install.rb setup
ruby install.rb install
Thanks to a googled gist for the nudge(handholdingpush) in the right direction.
