Ok, so I think almost everybody has either slammed Marissa Mayer about the new Yahoo non-remote worker policy or said that it’s the medicine they have to swallow. Very few are actually pointing out however, that Yahoo was probably just really bad at managing their remote employees. In the end, I don’t care, that just means there are now going to be more people who are probably great that will be available in a tech market that is happy to hire the talent!

But I do digress, I have something else to talk about that is actually productive. I’m going to kick this off with a short story, that actually inspired me to write this post.

Remote Workers Unite!

I was in the office, a coworking office called NedSpace in downtown Portland with my fellow Bashoians Eric Redmond (@coderoshi) & Chris Tilt. Generally we all work remotely, because everyone at Basho is remote. The entire company, from CEO to HR to Marketing to Engineering, everybody is remote. Basho does a solid job of working like this, it is indeed, a modern Internet enabled software company. However today we were all in the office.

During the day I pulled up Scott Hanselman‘s Blog Entry “Being a Remote Worker Sucks“. I found this on twitter and shortly after reading it, tweeted,

@shanselman & also, you ever feel like some convo & hacking you are always welcome in PDX to drop into @nedspace or such. 🙂

— Adron Hall (@adron) February 27, 2013

Case Study Coffee

Within a few minutes, lo and behold in the glare of my Apple Cinema Display I see Scott Hanselman walk up behind me! (Isn’t this building secure?!!? Scott’s name is now Hacker Hanselman!) Wow, that doesn’t happen everyday or does it? So Eric & Chris finished up some coding. Chris headed off to return home, where he remotely works from. However Eric, Scott & I headed out for a stroll through the city of Portland to Case Study Coffee. We had a great conversation, discussing all sorts of blog entry ideas, Node.js oddities, duplications between Rail & Node.js & Java & .NET and all sorts of other things. I mean, you probably know how it goes when you have three geeky people going on endlessly about awesome nerdy stuff. Simply put, we covered a lot of topics.

…that’s when I thought…

Offices Are Often The Worse Place to Cross Pollinate Ideas

Not a little bit, but likely the absolute worse places to cross-pollinate ideas. But then I got to thinking a little bit more. Is Yahoo on to something? Is there a need or a reason why people should be in a similar place? I mean, I know for a fact the most rapid learning I ever had was pair programming with other coders. But I’ve done this in an office and outside of the office, at coffee shops and hackathons, on the rooftop of buildings and in dark and dreary bars. I’ve paired with a lot of coders and learned a lot by doing that.

Another question came up, is it really important to be in the office or is it important to be near others you are working with? More of that thinking and remembering things and more experiences popped into my mind. Whew, this was becoming a serious thinking session. I’d also had a great experience working remotely and learning at practically the same rate with friends. We were all working on an open source project. We asked questions in general chat on IRC or other places, and got instant feedback and help when we needed it. We’d put ideas into chat and discuss them readily and sometimes excessively. We weren’t anywhere near each other, specifically we were about 1400+ miles from each other in different time zones. But it worked and it worked damn well!

My correlations in trying to figure out, should employees be in office or out of office could go on. As Eric said when we all returned form the coffee shop, “correlations do not show causation, but they sure as hell imply it“. Well, I didn’t want to just imply onsite or remote work is better I wanted to know what really works or doesn’t. More thinking ensued and then…

Freedom Punched Me In The Face

Then it hit me. Geographic location doesn’t make any difference. The difference, which also makes Yahoo’s demand for no more remote working, is again the freedom of the individuals involved. The freedom to work where we are needed with who we ought to and need to and when we are most efficient and capable of performing the work best. The key is this freedom is granted, and that driven self organizing individuals make use of this freedom. It may be that one day we might end up in the office while another day we end up in a park, at home or in some coffee shop.

So forget remote working or in office working. These things aren’t correlated to someone being productive or not, the core reasons someone is productive is the ability that they have the freedom to be productive in the way that best works for them and for the company they’re providing services for. The most important thing is being able to give freedom to those doing the work to be productive. Remote or not is pure distraction and in turn is bullshit.

Don’t get distracted by the remote or onsite worker debate, figure out the best ways to work with your employees based on individual freedom. You’ll have far more productive individuals than any existing hierarchical corporate structure nonsense.

Today, albeit by obliviousness to the holiday, had scheduled “Riak Office Hours” at NedSpace today. Even with the holiday, we had a great turn out. Generally Office Hours & Open Hack type of meets are small, often 2-5 people. Today we had a whopping 10 people turn out!

Open Ended Topics

Each meet we have a variety of topics, from a tutorial on getting started with Riak to discussion around using Riak or Redis to cache data for Riak distributed across geographic regions.

Dark Horse Comics, read them in digital format or original formula, They ROCK!!

In the case today, we dove into the finer nuances of Dark Horse Comics and how their mobile apps use data across caching, tiered access, and on server and on mobile synchronization across the web application. All very interesting and provides insights not to just one person or team, but to anybody and everybody there involved in the conversations. There are lots of solutions to be had, the real problem is just getting to the right one.

Next to bat Ed Borasky, Github @znmeb and Twitter @znmeb and I discussed “Hacks & Hackers”. Ed works a lot these days with Node.js, all sorts of databases, and media collateral. He’s often found digging through data and will soon be digging through some Riak experimentation. For more on Ed’s work and efforts, check out Computational Journalism Publishers Workbench.

Riak Office Hours, Part III

The next Riak Office Hours is coming up on March 4th. To check it out, please RSVP, and even if you can’t make the office hours feel free to join the group to stay abreast of upcoming meetups, presentations, workshops or other events in Portland related to data, data science, distributed computing, Riak, Basho, Erlang, web machine and software in general. We have a good time and look forward to you joining the group. Cheers!

…and now back for my deluge of Erlang, Riak, C#, Node.js + JavaScript and whatever else…

The first few parts of this series include:

• Up and Running With Erlang
• Installing QuickCheck for Great Testing
• Ubuntu Erlang Dev & EUnit

This continues the series, with the intent of getting to “Distributed Coding” with this all ramping up around Erlang and distributed programing in general. In this entry we’ll jump into some of the basics of Erlang and the shell that we can use to test and write some code.

Erlang Basics : The Shell & Some Integers

Before getting to deep into things, here’s some basic shell usage commands and integers to get a feel for the Erlang shell. To start the shell just type erl, which will present the following in the terminal.

$ erl
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1>

To exit the shell just type “q().” and hit enter like this.

$ erl
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1> q().
ok
2> $

It’ll execute a second line that will dump you back out to the terminal. One thing to note, is that when you execute “q().” it drops to a second line numbered two above. If we start the shell back up again and type in some actual code we’ll see that the numbers increment. The idea is similar to each line of code in a code file.

Start up the shell again and type the following.

$ erl
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1> q().
ok
2> Adrons-MacBook-Air-2:erlangMagic adronhall$ clear
Adrons-MacBook-Air-2:erlangMagic adronhall$ erl
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1> -69.
-69
2> 2#1212
2> 2#1212.
* 1: syntax error before: 212
2> 2#1010.
10
3> $A.
65
4> $B.
66
5> $a.
97
6> 2*2+100.
104
7>

What I’ve done here is enter some values, primarily all integers. These integers, on the first line is a negative integer. By entering a “.” at the end, the lines executes and returns the value. In this case, the value is “-69”.

The second line, I entered “2#1212” without entering a period to finish the line of code. Thus, nothing executes.

The third line I entered the same thing as the second, “2#1212” which is not valid, giving us a syntax error. On the next line I tweak my value just a bit, entering a valid hexadecimal number “2#1010” with the appropriate period at the end. The line executes and it displays the decimal integer “10”.

So far at this point, this shows us several things:

• Every line must end with a period to execute.
• We’ve seen a negative integer, a positive hexadecimal integer and an invalid integer and the error that throws “* 1: syntax error before: 212”.
• We’ve seen that when the line in the shell successfully executes we get the next incremental line, such as “-69.” was on the first line, the first successful second line was the “2#1010.” value and as we move through each line above the code line increases.
• A valid integer includes -69, but also includes a hexadecimal representation of an integer such as “#2#1010”.

Moving beyond these values the “$A”, “$B” and “$a” are all ASCII representations and return their numeral values.

On line six I actually perform a basic calculator type multiplication and addition of integer values, which returns the integer value 104.

Now that we have the shell start and stop figured out, that gives us a platform in which to start stepping through some of the basics of Erlang.

Erlang Floats

Above we’ve seen how regular integers are represented such as 2, 100 or -69 along with hexadecimal and ASCII numeric representations. For floats, we’re looking at similar uses. Spool up the shell again and try out these examples.

1> 21.21.
21.21
2> -1234.1234.
-1234.1234
3> 3042.1.
3042.1
4> 650.21
4> 650.21.
* 2: syntax error before: 650.21
4> 650.21
4> 650.21.
* 2: syntax error before: 650.21
4> 650.21.
650.21

Lines 1-3 show some standard floats. On the first part of line four I left off the period to show that it won’t accept the line, even with a period in it, because of the numbers after that period. In that second line number four I’ve added the period, but it throws a syntax error.

Then note I did the exact same thing again, to show that entering a float and then adding the period, will still leave the float broken because of the way the Erlang compiler is waiting to execute the code. It’s almost like the compiler sees “650.21650.21” which of course doesn’t mean anything. However on the fifth line of the number four lines, I finally get a good execution and it displays the float I’ve entered “650.21”. Be sure when you’re fixing values like this, the compiler could be stuck in mid execution, because without the period at the very end, being the last character on the line, the compiler is still waiting for the period to actually start the execution.

Mathematical Operators, You Know Those Things That Help Math Explain the Universe!

Erlang has the standard operators that you’re used to, especially if you’ve done anything with a language based around C syntax such as JavaScript, Java, C#, C++, Objective-C… well, pretty much every regularly used static typed language and more. In functional languages these operators are pretty common too. If any don’t look familiar, be sure to get intimate with them. You’ll find them all over Erlang code.

The + and – characters act as addition and subtraction, but also as unary operators. In order of precedence, the unary operations of the + and – have the highest precedence and the addition and subtraction usage of the + and – have the lowest precedence.

The * and / signify multiplication and division. They’re precedence is just below that of the unary operators of + and -.

Two that are a slight bit unique, is the usage of “div” and “rem” for division and remainder, for integer numbers. This begs to bring up the point that whenever an integer is involved in multiplication, division, addition, subtraction or other operations, it is coerced into a float when being operated on against another float. Such as 2 + 3.47 would mean that 2 is turned into a float before it is added to 3.47.

Here’s some examples of operations occurring between numbers via the shell.

$ erl
Erlang R15B01 (erts-5.9.1) [source] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1> +15.
15
2> +2.
2
3> -11.
-11
4> 11 div 5.
2
5> 12 div 5
5> .
2
6> 15 div 5.
3
7> 14 div 5.
2
8> (12 + 345) div 12.
29
9> (3+2)/5.
1.0
10> 2*3*4.12.
24.72
11> 1+1+1+1+13+-2.
15
12> 2/3 + 3/4 -- (1/2 + 2/3) -- 1.
-0.75
13> 14 rem 5.
4
14>

These examples show a number of effects of how the operators work. Notable is how everything looks very much like simple math being done. This is one of the more readable aspects of Erlang. Note also that the rounding generally goes down.

This coming Wednesday I’m aiming for a Riak Beer Hack. Yup, it’s right after the Riak Nerd Lunch in Seattle. Thanks Amtrak Cascades for the ability to get from Seattle to Portland with wifi and not missing a beat! Train travel for the win!

Sample Appropriate Beer & Coffee Swag

At Bailey’s my intent is to bring a deployed Riak Environment and we’ll work – stepping through from the beginning – of connecting an application to the Riak back and and research the latest Beer APIs and discuss things to build like the Digital Pour Dashboard/Menu while enjoying some of the best beer in Portland at Bailey’s Taproom.

Feel free to come ready to hack with Ruby, Erlang, Haskell, C#, Java, JavaScript, PHP, Python or one of the other clients. I might not have any idea how to connect whichever client you’d roll with, but we’ll all be working together to figure it out! So bring your ideas, your laptop and we’ll have a round or two of code and beer (or whatever your beverage of choice). RSVP and I’ll be sure to bring you some swag – swag that you’ll enjoy or your money back!

Recently a friend of mine and fellow coder, harkening back to my Russell Investments Enterprise Developer days posed the discussion of Redis versus Riak. Well, first off, I thought I myself needed to write down a line by line comparison. I’ve worked with both in various ways but I’d never really thought about them lined up side by side. Often I think of the two pieces of technologies as complementary in various ways. But before I dive into that, let’s take a look at the stats side by side of each.

Redis is primarily something you’re going to use to move data in and out at crazy fast speeds. However, when you need to store data, it isn’t ideal. There are ways, but it tends to work better handing off to something else to store the data. However Riak on the other hand isn’t always the fastest database, but it’ll withstand serious hits and still maintain integrity of data. It is also tunable for writes, reads and other characteristics that enable tuning and also integrity of the data among nodes. The more nodes in Riak you have the higher available iOPs and fault tolerance. The other thing that Riak can do over time, is truly scale from a horizontal and vertical perspective. Grow Riak tall and wide, it’ll give you linear performance and integrity improvements.

The thing I’ve seen over and over, is Riak as a store and Redis as a cache or other temporal specific data store for websites or other high transaction systems. Overall each serves a very specific purpose but work well in conjunction with each other when you’re rolling together an extremely high performance architecture with an extremely highly available back end data store.

If you’re in Seattle and up for lunch this Wednesday, join me for the Riak Nerd Lunch.