Java SE 8 for the Really Impatient Book Review

Last year I started working on Java 8, but knew very little of it.  I needed a way to dive into the new features, best practices, while working on a project that was going on production with a hard deadline.  I decided to grab the Java SE 8 for the Really Impatient by Cay S. Horstmann.  I put so many tabs on so many great topics/ideas that a picture is well worth it.

Few things that I picked up from the book is composing Optional value functions with flatMap

The chapter that I focused was on streams.  In my opinion, is the best feature from Java 8. Here, I learned how to transform a stream into a Map result and some of the issues that you have to keep in mind.  For example, if there is more than one element with the same key, the collector will throw an IllegalStateException.
You can override the behavior by supplying the a third function argument that determines the value for the key, given the existing and new value.
Get the book!  I'm sure you guys will enjoy it.

Java 8 Lambdas Book Review

O'Reily's Java 8 Lambdas by Richard Warburn is a "must have" if you are starting with Java 8 or functional programming. The book covers the different features of Java 8, and how using lambdas make you a better programmer. Here are some topics that catched my attention:

• Streams - separate the "what" from "how" 
• Patterns to refactor using lambdas 
• Higher order functions 
• Lambda expressions can be used to make many existing design patterns simpler and more readable, especially the command pattern 
• Lambda-Enabled Concurrency 
• Lambda-Enabled SOLID principles 

 I recommended the book to my team and in my Meetup group - I'm the organizer of the Miami JVM Meetup. I use the book constantly while doing code reviews. Again, any developer, team leader, or architect who is starting to use Java 8 should get this book. I really enjoyed the ending and finally understood the Reactive Programming approach. As the author mentioned,

The critical design tool for software development is a mind well educated in design principles. It is not...technology. - Craig Larman

BDD in Action - Book Review

Finished reading Manning's BDD in Action (behavior-driven development) by John Ferguson Smart which I found it very insightful.  There are four things that struck me about this book:

1. Don't write unit tests, write low-level specifications
2. Favor outside-in development
3. Learned about Spock framework
4. There is a difference between a story and a feature

I used RSpect before but without a clear understanding of BDD, so I wrote unit tests (test scripts) rather than low-level specifications.  The book explains why BDD is important along with details steps and examples.  BDD is when we write behavior and specification that then drive the software.  One of the key goals of BDD is to ensure that everyone has a clear understanding of what the project is trying to deliver, and of the underlying business objective of the problem. BDD is TDD but with better guidelines or even total new approach to developing.  This is why wording and semantics are important: the tests need to clearly explains the business behavior they're demonstrating.  It encourages people to write tests in terms of the expectations of the program's behavior in a given set of circumstances.

When writing user stories we were told to use this template:
As a <stakeholder> I want <something> so that I can <achieve some business goal>.

Once you have a story, then you have to explore the details by asking the users and other stakeholders for concrete examples.

In BDD the following notation is often used to express examples:
Given <a context>: describes the preconditions for the scenario and prepare the test environment
When <something happens>: describes the action under the test.
Then <you expect some outcome>

Example:
Story: Returns go to stock

In order to keep track of stock
As a store owner
I want to add items back to stock when they're returned

Scenario 1: Refunded items should be returned to stock
  Given a customer previously bought a black sweater from me
  And I currently have three black sweaters left in stock
  When he returns the sweater for a refund
  Then I should have four black sweaters in stock

Scenario 2: Replaced items should be returned to stock
  Given that a customer buys a blue garment
  And I have two blue garments in stock
  And three black garments in stock.
  When he returns the garment for a replacement in black,
  Then I should have three blue garments in stock
  And two black garments in stock

As the book Specification by Example mentioned, instead of waiting for specifications to be expressed precisely for the first time in the implementation, successful teams illustrate specifications using examples.  The team works with the business user or domain experts to identify key examples that describes the functionality.  During this process, developers and testers often suggest additional examples that illustrate the edge cases or address areas of the system that are particular problematic.  This flushes out functional gaps and inconsistencies and ensure that everyone involved has a share understanding of what needs to be delivered, avoid rework that results from misinterpretation and translation.

Besides understanding the difference of unit tests and specifications, the book also talks about the difference of features vs. user stores.  They are NOT the same.  A feature is a functionality that you deliver to the end users or to the other stakeholders to support a capability that they need in order to achieve their business goals.  A user story is a planning tool that helps you flesh out details of what you need to deliver for a particular feature.  You can have features without having stories.  Is a matter of fact, a good practice is to summarize the "Given When" sections of the scenario in the title and avoid including any expected outcomes.  Because scenarios are based on real business examples, the context and events are usually stable, but the expected outcome may change as the organization changes and evolves the way it does business.

Besides the language syntax, I discovered the Spock framework.  It lets you write concise and descriptive tests with less boiler plate code than would be needed using java.  The syntax encourages people to write tests in terms of your expectations of the program's behaviors in a given set of circumstances.

Example:


While I was reading this book, two quotes came to my head:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live - M. Goldin.

Programs must be written for people to read, and only incidentally for machines to execute - Adbson and Sussman.

The other insightful thing that I learned is that BDD favors an outside-in development approach.  Which they include:

• Start with a high-level acceptance criterion that you want to implement
• Automate the acceptance criterion as pending scenarios, breaking the acceptance criterion into smaller steps
• Implement the acceptance criterion step definition, imagining the code you'd like to have to make each step work
• Use these step definition to flesh out unit tests that specify how the application code will behave
• Implement the application code, and refactor as required

There are many benefits of outside-in development, but the principle motivations are summarized here:

• Outside-in code focuses on business value
• Outside-in code encourages well-designed, easy to understand code
• Outside-in code avoid waste

As I mentioned, I enjoy the book and I found it very insightful.  Some (if not all) the ideas of the book has been around for decades.  I believe that this book is great for an architect, programmer, testers, project manager, product owner, and scrum masters.

Validate Map Collections via Matchers

I was introduced to Hamcrest Matchers by the 3C team.  I am really liking it.  Today, I stumbled on a validation of a Map.  Here is how I usually solved the problem and then how I solved it using the syntax sugar of Matchers.

Lambdas and Java 8

Java 1.8 introduces the concept of streams, which are similar to iterators.

Why Lambdas are good for you:

• Form the basis of functional programming language
• Make parallel programming easier 
• Write more compact code 
• Richer data structure collections 
• Develop cleaner APIs 

 Lambdas Expression Lifecycle - think of them as having a two stage lifecycle:

1. Convert the lambda expression to a function.
2. Call the general function

Streams have two types of operations: intermediate and terminal.
Intermediate operation: specifies tasks to perform on the stream's elements and always results in a new stream.
filter: Result in a stream containing only the elements that satisfy a condition.
distinct: Result in a stream containing only the unique element.
limit: Result in a stream with the specified number of elements from the beginning of the original stream.
map: Result in a stream in which each element of the original stream is mapped to a new value (possibly of a different type).
sorted: Result in a stream in which the elements are in sorted order. The new stream has the same number of elements as the original stream.


Terminal operations initiates processing of a stream pipeline's intermediate operations and produces results.
forEach: Performs processing on every element in a stream.
average: Calculates the average of the elements in a numeric stream.
count: Returns the number of elements in the stream.
max: Locates the largest value in a numeric stream.
min: Locates the smallest value in a numeric stream.
reduce: Reduces the element of a collection to a single value using an associative accumulation function (e.g. a lambda that adds two elements -- in Scala this is the "map" operator).


Mutable reduction operations: creates a container (such as a collection or StringBuilder)
collect: Creates a new collection of elements containing the results of the streams's prior operations.
toArray: Creates an array containing the results of the stream's prior operations.


Search operations
findFirst: Find the first stream element based on the prior intermediate operations; immediately terminates the processing of the stream pipeline once such an element is found.
findAny: Finds any stream element based on the prior intermediate operations: immediately processing of the stream pipeline once such an element is found.
anyMatch: Determines whether any stream elements match a specified conditions; immediately terminates processing of the stream pipeline if an element matches.
allMatch: Determines whether all of the elements in the stream match a specified condition.

Examples:

Refactor: 

This has done so many different changes to some of my code. Here are some example of before and after: Before: I wanted to printout some of the results and so I leveraged Spring's CommandLineRunner.

 Here's the after code: Another example fetching a collection of records from a database: I can refactored it doing this:

Changing Java SDK in IntelliJ IDEA 13

We just migrated to Java 1.8.  In my personal computer, I installed the JDK 1.8 and make sure that Maven was running fine in using the latest Java version.  I'm using a Mac, so when I ran it in Terminal everything worked.  However, when I ran it in my IntelliJ IDEA, it said that it was running Java 1.7.

To changed it, go to the following menu: File, Project Structure, then click on Project.
Here is where you can set the SDK for your project.  Just change it to the right SDK and that's it.

Happy coding.

Learning Cassandra

I just finished reading Practical Cassandra.  I enjoyed this book and it helped with my presentation at Rokk3r Labs in Miami Beach.  You can tell that Russell Bradberry and Eric Lubow spent sometime thinking about this book.  I like that it's straight to the point for a developer, but it is also useful for sysadmins and managers.  I enjoyed the troubleshooting and "use cases".

The book mentions, "where Cassandra fits in".  This is a question that I constantly get when talking about Cassandra.  Many people want to know, "why not [NoSQL database of your choice]?".  The short answer is: if you want fast writes, multi-data center support baked into your system, a truly scalable system with tons of metric, then you should consider Cassandra.  However, I always follow my answer by saying that the best way to know if Cassandra fits into the role, is to understand it.  When I started using it, I had to stop myself thinking about all that I know about data modeling with RDBMS.  Most of the stuff that we learned in RDBMS is actually an anti-pattern for Cassandra - normalization, build your model first, index with high-cardinality, leverage joints.  Don't think of a relational table, think of a nested, sorted map data structure.

Tunable Consistency and Polyglot Databases

Many people don't understand that you can tune the consistency of Cassandra.  The followings are the configuration that you can have for reads and writes:

• ANY: is for writes only and ensures that the write will persists on any server in the cluster.
• ONE: ensures that at lease one server within the replicate set with persist the write or respond to the read
• QUORUM: means the read/write will go to the half of the nodes in the replica set plus one.
• LOCAL_QUORUM: it's just like "quorum" except that it is only for the nodes in that data center.
• EACH_QUORUM: is like "quorum" but ensures a quorum read/write on each of the data centers.
• ALL: ensures that all nodes in a replica set will receive the read/write.

One of the things Cassandra does not do, is joins or ad-hoc queries.  This is a something that Cassandra simply doesn't do and other tools do it better (Solr, ElasticSearch, etc).  This is what people are calling to Polyglot Data.

Gossip vs Snitch

Practical Cassandra helped me understand the difference between the "gossip" and "snitch" protocol.  This is something that I struggled time and time again.  Gossip is the protocol that Cassandra uses to discover information about the new nodes.  When bringing a new node into the cluster, you must specify a "seed node".  The seed nodes are a set of nodes that are used to given information about the cluster to newly joining nodes.  As you can imagine, the seed nodes should be stable and should point to other seed nodes.

The snitch protocol helps map IPs to racks and data centers.  It creates a topology by grouping nodes together to help determine where data is read from.  There are few types of snitches: simple, dynamic, rack interfering, EC2, and Ec2MultiRegion.

• Simple snitch is recommended for a simple cluster (one datacenter as one zone in a cloud architecture).
• Dynamic snitch wraps over the SimpleSnitch and provides an additional adaptive layer for determining the best possible read location.
• RackInferringSnitch works by assuming it knows the topology of your network, by the ocftets in node's IP address.
• EC2Snith snitch EC2 Snitch is for Amazon Web Service (AWS)-based deployments where the cluster sits within a single region.
• EC2MultiRegionSnitch is for AWS deployments where the Cassandra cluster spans multiple regions.

Node Layout

Prior to Cassandra 1.2, one token was assigned to each node.  Whenever you had a node that would have a lot of load of data, that would be consider a "hot spot".  Most of the times, you will just add another node to leverage the "hot spot", but then you had the "rebalance" the cluster.  Virtual nodes or vnodes, provide a Cassandra node with the ability to be responsible for many token ranges.  Within a cluster, they can be noncontiguous and selected at random.  This provide a greater distribution of data than the non-vnode paradigm.

Performance

The performance chapter was also another very interesting chapter.  Being a developer it introduced me to common *nix tools like vmstat, iostat, dstst, htop, atop, and top.  All of these tools provide a picture of usage.  It also explained how instrumentations goes a long way.  Also, if one node becomes too slow to respond, the FailureDector will remove it.

An easy optimization for Cassandra is putting your CommitLog directory on a separate drive from your data directories.  CommitLog segments are written to every time a MemTable is flushed to disk.  You can do this setting in the cassandra.yml by setting the data_directory and commitlog_directory.

Metrics

Cassandra goes out of her ways to provide lots of metrics.  With all these metrics you can do capacity planning.  Once you start getting all these metrics, you'll be able to differentiate trends and be able to proactively add or remove nodes.  For example, you can monitor the PendingTask under the CompactionManagerMBean to know the speed and volume with which you can ingest data, you will need to find a comfortable set of threshold for your system.  Another example is to monitor the high request latency, which can indicate that there is a bad disk or that your current read pattern is starting to slow down.

These are some of the metrics that you can get via JMX:

• DB: monitors the data storage of Cassandra.  You can monitor the cache and the CommitLogs, or even information about the ColumnFamily.
• Internal: these cover the state and statistics around the staged architecture (gossip information and hinted handoffs).
• Metrics: these are client request metrics (timeouts and "unavailable" errors).
• Net: these metrics monitored the network (failure detector, gossiper, messaging service, and streaming service).
• Request: these are metrics about request from the client (read, write, and replication).

There are still a lot of stuff that I need to learn about Cassandra.  Specially about the data model.  It's very tricky to start thinking about your queries (pre-optimized queries like Nate McCall calls them).  In all, the book does covers the basics .

Case for Code Reviews

I have been doing code reviews for about six months at 3CInteractive.  Since I'm so new at it, it's hard for me blog about "best practices" or even do a presentation on code reviews.  Therefore, I decided to have an open space meetup at our Miami JVM Group.  The open space will be around "effective code review process".  I'm hoping to learn about the following: Who is using it?  Who are not using it and why?  Who thinks they're not useful and why?  What have they learned?  What were some of their challenges?  This post is based on my experience and some of my lessons learned while working with internal and offshore teams.

Benefits of Code Reviews

• You write better code when you know it will be reviewed.
• A second (or third, or fourth) set of eyes will help spot defects.  This is very similar to pair programming, but it works even better if you're working with an offshore team.  It's also a great way of learning new APIs.  For example, someone could tell me that my code can be easily done using the Guava library, or that the code is actually an "aggregator" Enterprise Implementation Pattern, and I should probably look at Camel.
• More than one person understand your code (cross-pollination or avoid silos).  Having more than one person look at your code helps spread the knowledge and context of the problem or solution.
• Reducing the learning curve for new developers.  I believe that even junior developers should be part of the code review process.  It's a great way for them to learn about the code base and they become more productive.

What To Look For

• Bad design.  Highlight issues such as SQL injection, look out for lack of design patterns, or anti-patterns.  Things like separations of concern, encapsulation, and apply certain basic OOD principles - DRY, encapsulates what varies, open-close principle, etc.
• Performance hazard.  For example, memory leaks.
• Lack of clarity - the application should work and the code should be readable.  For example, a class named "SomethingServiceImpl" with no documentation on the class will be highlighted and will prompt a change request to the developer.  Also, a big nested if statement that is not quiet clear will prompt a change request. 
• Not consistent or not according to standards.  Having a set of standards makes code reviews a lot simpler.  It also sets a norms for the team.  For example, not using Domain-Drive Development standards, consolidating APIs (Guava vs Jakarta Commons), having a handful of languages, and having a code style rules.

What Not To Look For

• Premature optimization.  Don't try to optimize all of it at once.  As my buddy Tyler mentions, "make it work, then make it better".
• Skills and expertise gaps.  In our company, we allow all developer to do code reviews, including junior developers.  These developers gain a lot of knowledge about doing code reviews.
• Personal style.  If the CTO goes over and says, "I wouldn't do it like that" it bring noise to the process.

Quality and Dissemination of Knowledge 

My team is responsible for improving code quality, lower defects in code, improve communication about code content, and teaching and mentoring of junior developers.  Code reviews has helped us on shorter development cycles, more customer satisfaction, and more maintainable code.  But most important, it has help us spread the knowledge and norms.  As per the book 97 Things Every Software Architect Should Know,

Chances are your biggest problem isn't technical

Most projects are built by people, and those people are the foundation for success and failure.  So, it pays to think about what it takes to help make those people successful.

Find Type of Vagrant VM is Running

I am really enjoying Vagrant.  It's one of those tools that are indispensable.  However, today I wanted to install a CentOS VM in my application and I didn't remember the version name that I was using in my other VMs.  To find out, the only thing that you have to do is to check a previous VM.  Here's an example:
vim ~/vagrant_boxes/kafka/Vagrantfile
You will be able to see the version inside the file:

Strata 2014 - Newbie Perspective

Marc Andreessen noticed that software is eating the world.  I see the same thing with Big Data.  Big Data is shaping the world around us.  It has been used on presidential elections, weather reports, consumer analysis/sentiment, fraud check, etc.   Strata conference is the epicenter of new technologies, use cases, and new innovations related to Big Data.  I've been meaning to go there for quite some time.  Previously, I purchased the videos from O'Reilly because I couldn't make it.  Thanks to my current company, 3C (they're pretty awesome), I was able to go along with five of my coworkers.  It's the place where you can meet the experts, the main committers, and ask them questions.  If your eyes get dilated when you talk of Hadoop, or you get exited when you need to solve a problem that has to do with a huge amount of data including the famous "three V's" (volume, velocity, and variety), then this conference is for you.  This is a quick summary of my experience of the conference.

The conference revolved around four clusters:

1. How quickly can you get the data into your system (ingest)
2. How fast can you show the results
3. It's all about presentation (charts)
4. Big Data doesn't mean Hadoop

How Quickly Can You Get Data

The presentation that left me mesmerized was Spark!  I can't wait to use it.  It is a very compelling product and it's now backed up by Cloudera.  With Spark you can do the following:

• Get a compute engine for Hadoop data - no need to reinvent the wheel
• Speed up! A 100% faster MapReduce engine
• Sophisticated: it runs all the sophisticated algorithms.  Get access to a library of sophisticated algorithms
• A a big community behind it; the most popular Big Data open source (followed by Hadoop)
• Learning from the big guys - Yahoo!, Conviva, and Cloudera are using it

Not to mention that it comes integrated with a analytic suite (Shark), a large-scale graph processing (Bagel), and real-time analysis (Spark Streaming).  This is nice because rather than doing Hive, Hadoop, and Mahout, and Storm, I only have to learn one programming paradigm.

How Fast Can You Show The Results

Twitter explains how they monitor millions (+5,700 tweets per second) of Time Series.  The presentation was superb.  I found out that the stack that they're using, named "Observability", is composed on: Finnagle, Cassandra, and query language and execution engines based on Scala.  Although is a work in progress the stack is about three years old.  I hope that they open-sourced it stack so I can get more context on how they monitor a large distributed system.  

Another very interesting product was Google's Big Query.  This was one of those presentations in which we (my team and I) stumbled upon by accident.  The presentation showed how to use Google's toolkit: Freebase, Maps, and BigQuery to do analytics.

It's All About Context, Results, or Charts

Another company that impressed me was Trifacta.  With their tool you can clean data, see the model (graph) and recursively do it again in case you see patterns or not.  The tool is targeted to data scientists, data wranglers, and data analysts.  It's a great tool to mine data data, but most important, you can clean the data and show the results with relative ease.

IPython: This rekindled my interest in Python.  IPythons notebooks are great for data scientists.  You can get code, text, and graphics all in one page, so it's the perfect tool to show quick results.  It's not that Python wasn't a popular language for data scientists.  NumPy library provides a solid MATLAB-like matrix data structure, with efficient matrix and vector operations.  It also provides other great APIs like SciPy and Pandas.

Big Data != Hadoop

Two topics that opened my eyes were Mesos and YARN.  Mesos, what Twitter uses to manage its clusters, is similar to YARN (Yet Another Resource Negotiator).  The Hadoop 2.0, or YARN, it's becoming more of an environment and operating system; not just a MapReduce.  With YARN, the JobTracker is gone.  The ResourceManager is what does the job of the JobTracker.  The ResourceManager (RM) is a scheduler - it allocates resources based on a pluggable scheduling algorithm. RM manages and monitors all the applications, so it strictly limits to arbitrating available resources.

One of our favorite (me and two of my buddies), was Netflix Data Platform by Kurt Brown.  A different and a great presentation.  Rather than going on the technology side, they explained how the culture is intertwined with their technology stack or decisions.  For example, they talked about the reason for using "the cloud".  Obvious reasons like: it's cheaper, much flexible (growth, a better place to do tests/spikes), and having multi data center is definitely a plus.  Also, Amazon and RackSpace have great services such as SQL, EMR, and S3.  But the main reason is "focus".  They are focused on getting movies and increasing their audience rather than to focus on the "plumbing".  They expressed their commitment to "open-source software" (OSS).  They mentioned the great talent that they can get and how they can "manage their own destiny" by following these principles and using these tools.

Netflix explained their philosophy and how it's the "soul" of their decision (technical and business).  For example, they keep keyboards, mice, and other peripherals in vending machines (they are free), so that everyone knows to "act in Netflix best interest".  Furthermore, every decision or project needs to answer a basic question: "what value are you adding?".  They apply the rule "accept that things will break".  Because of this, they build safety nets around their systems.  Again, it was a very nice and interesting presentation.

I really enjoyed the conference.  I also just purchased the videos.  Which I highly recommend!!  During the next few months, I'm going to try to learn some of these tools and present them at the Miami JVM Meetup.  Hopefully I can get to see you there, or better yet, hope to see you at Strata 2015.  If you're going to either one of these events, let's meet up and share a beer...or two and discuss Big Data.  I promise that my eyes will get dilated.

El Dilema de Ser Buen Samaritano o Come Mierda

Siempre me a gustado ayudar a la gente, pero hay veces me pongo a pensar…soy "buen samaritano" o un "come mierda"?  Desde pequeño me gusto salir y hablar.  Mi mamá siempre me dijo que hablo “hasta por los codos”.  Lo que he notado es que ahora, muchas personas me suelen hablar y pedirme por cosas.  Algunas personas se acercan a mi para venderme algo, y otras para ayudarlas.  La verdad es que muchas personas dicen que yo soy un muchacho “agradable”, otras personas dicen que soy “simpatico” (me gusta), yo a veces pienso que tengo cara de "come mierda”.  Por ejemplo, es común que cuando voy a un mall, siempre las personas que tienen una tienda en un kiosco, siempre me llaman, “señor, le limpio el reloj?" o "Joven, tengo esto en especial.”  Siempre termino en decir, “no gracias" con mi sonrisa y sigo adelante, para que…para encontrarme con otros dos muchacho/as que me van a preguntar lo mismo.  Esto es muy común para mi.  Mi esposa siempre me dice que vea abajo para que no me persigan, pero hasta eso!  La otra ves, caminando en un estacionamiento con mi familia, una señora me paro en plena calle y me llamo.  Luego me dijo, “me puedes hacer un favor, se me desamarro mi zapato, me lo amarras?”  Y que es lo que hice?  Pues lo amarre…como buen come mierda.  Para consolarme, la señora era una anciana obesa.  Pero aun así, de todas las personas, tuve que ser yo?  Mi ultima escena de “buen samaritano” fue la otra ves que fui a desayunar con mi familia.  Apenas salí de el carro, un señor me vio y me dijo que su carro lo encerro con las llaves dentro de el vehículo.  Yo se, medio bruto el personaje, pero también yo soy super despistado - lo entiendo.  “Me puedes llevar a casa para agarrar mis llaves de repuesto?  Vivo bien cerca.”  Mi esposa solo me vio, me dio un sonrisa, y me dijo que mientras iba a agarrar la mesa con los niños.

La verdad muchas veces me pongo a pensar, “voy a ponerme así, todo cabrón y mandar al diablo a esa gente”.  Pero no es como soy yo.  Como dije, me encanta hablar!  Cuando hice mi ultima “labor” de buen samaritano, le pregunte a el señor (algo mayor) que cuantas personas le había preguntado.  El me respondió fui el primero, “tienes la pinta de ser amable”.  Yo pensé, "mas bien, cara de come mierda.”

Después de tanto tiempo así, viéndolo en retrospectiva, no solamente me da mucho agrado ayudar, pero también me ha ido muy bien con mis pequeñas labores.  Como dije, se siente bien ayudar a la gente.  Ademas, creo que da un buen ejemplo a mis dos hijos (tengo uno de doce y otra de 3 que cree que tiene trece).  Y más aun cuando lo haces sin pensarlo mucho o pedir algo en cambio.  Aunque nunca he pedido nada, siempre termino notando cosas bonitas.  Como cuando el señor que dejo las llaves en el carro pago mi desayuno, en el caso de el año pasado alguien me compro un par de zapatos de $120, solamente porque tenia cara de buena gente.  Al parecer, a los de cara de come mierda, tiene mucha suerte.

Un abrazo!
Marcelo

Disruptive Possibilities: How Big Data Changes Everything

I was looking forward to this book because of the title. I was under the impression that I was going to find concrete examples on how Big Data has affected and disrupted some industries. Best of all, I thought that I was going to read what industries will be impacted and how.  The book showed some examples at the end, but in my opinion, it leaves something very important: speed and sophistication. 

I just came back from Strata 2014, which is why I was looking forward to this book, and when I heard Matei Zaharia's keynote, it was all I needed to know about the current disruption of big data. Nowadays, big data storage is becoming commoditized, so the best value added is speed (how quick you can get the answer of your problem) and sophistication (run the best algorithms on the data). The book doesn't mentioned this but it might be because of its age - things are moving super quick on Big Data.

Some of the things that the book does well:

• Introduces some history about the Big Data problem
• How it affected some of the silos technologies like RDBS
• How they solve the scalability issue

If you are a manager or someone that has no understanding of the world of Big Data, then I would recommended.  However, if you are a developer, data scientist, or data wrangler, then this book will be too basic.  The one thing that I highly recommend, if you are interested in this subject, is to attend (or at least purchase the videos) of Strata.

You can get the book here.

Happy reading,

Marcelo

My best decision of 2013

I started working at 3CInteractive (3Ci) as of March 29th, this is perhaps the best place that I’ve ever worked at.  This is a brief post of why this was my best decision of the year.  I didn’t want to write this post until the honeymoon period was over (usually after 4 months).  There were three factors that helped me make the decision (and why I continue loving) to work at 3Ci: 

• Culture: I wanted to work for a company who looked at IT as an innovation engine rather than a cost center.
• Team: I wanted to work with awesome engineers (very motivated, smart, and with a lot of experience).  Also, I wanted to be the dumbestperson in the room.
• Tackle big harry audacious goals: To be part of a company whose products revolve around big problems that would (without a doubt) have an impact to the bottom line.

I was introduced to 3Ci in 2007 when I was trying to sell a startup that I was working for by the name of Up-Mobile.  The startup wasn’t doing well in the US market, so I was handed the task of selling our customer based to another company.  During that time, I met with 3Ci’s senior management and some of their architects.  Their company was doing some similar things as our startup, unlike us though, they were able to evolve quick and found a potential market with top tier companies and a compelling product.  Many of 3Ci programmers were very involved in open source projects.  For good or bad, I was attached to Up-Mobile and I wasn’t ready to make a move.  Nevertheless, 3Ci left a great impression.  Later down the line, I became the organizer of the Miami Java User Group (MJUG) and Miami JVM Meetup.  3Ci was more than helpful to provide a venue, food, and beverage with no strings attached.  There was a big turnaround of 3Ci employees when I did presentations.  It turned out that they also do a lot of presentations on things that they are doing.  Also, they are committed to open source projects while keeping away from the golden hammer anti pattern - if you have a hammer, everything looks like a nail.  They had the motto of using the best tool for the problem.

Culture

When a lot of people think about the culture of a company, they think about the things that they can see and touch.  When you enter 3Ci, you’ll see the graffiti on the walls, the cool paintings, the guitars, motorcycles, and the free food.  But this is a byproduct of culture.  At 3Ci we have three rules that are unbendable:

• Build a sustainable company in the emerging market for enterprise mobile services
• Create a great culture that focuses on the personal and professional development of our team
• Do important work for quality clients

I came from a couple of small companies or startups (with less than 20 people).  When you work for a small company, you not only know everyone’s name, but you know what everyone is doing and why.  Although 3Ci has more than 100 people, and many of them are distributed, everyone on the team understands what the goals are because of these three rules.  The culture is what promotes the exceptional people working there, the proactive and ownership of tasks, breed result-focused, and the team.  3Ci's culture have created a set of values based on this culture:

We are not in the business for the business alone but for a higher purpose - to make lives better, to solve important problems, and to enjoy what we do. Our Data Scientist, Oliver, once said, “Don’t live a life to do a great work.  Live a great life, and then the great work will follow”.

3Ci strives to be one of the best places you will ever work.
Time and time again, you see that we become either the best place in South Florida to work or America’s most promising company.

We’re in it together

There is a sense of, “let me know if I can help” within 3Ci.  It’s also okay to fail as long as you learn from your mistakes.  The head of our data team, Gabe, once said to me, “Do not do things when you are frustrated or under pressure.  Rather do them when you're calm.  You don’t want to make things worse by doing yet another mistake”.  He is also the first one that holds my feet to the fire when something goes wrong.  The same goes with Alex, my boss and head of the Software Engineering.  It’s not a “don’t let it happen again”.  It’s more like, “We really messed up.  Why did it happen? What’s the root-cause of the problem.  Can we make sure that this doesn’t happen again through some process? Can we automate this issue?"

We’re champions of change
We need to change quickly and adapt.  Anyone with some experience knows this, but the one that are constantly thinking are those entrepreneurs that work at startups.  I learned early on my career that the life a technology company is composed of three: you either go big, stay small, or be eaten.  This was mentioned by Mike FitzGibbon (Fitz), president and cofounder, at the company's "All Hands Call", we need to be customer-centric and be able to quickly and effectively execute goals.

Team

One of the main engineers at 3Ci during 2007 was Alejandro (Alex), and I met him on an open source project (Kannel).  I checked some of his code, and I really like what he was doing.  But the best things about him was his curiosity.  He was a system administrator at 3Ci, yet he was learning Java at that time and committing to Kannel.  I was also a good friend with the one of the main committers and founder of Kannel, Stipe Tolj.  Stipe was also working for 3Ci as a consultant and knew Alex personally.  He told me about some of the things that the company was doing, and I was intrigued to say the least.  After a couple of e-mails, Alex and I pretty much hit it off.  At that time he was working in Europe, then he was promoted and moved to 3Ci (Boca Raton, FL).  The moment that I found out, I immediately sent him my resume.  During my interview, I met a couple of guys: Mauricio and Carlos (Carlitos).  Two of their best architects.  This is another way of knowing how good the company, they had a good technical interview process.  The interview was hard but I did well, so I was hired.  I’ve never looked back.  I highly enjoy it, and it’s the reason of why I make the 1.5 hour commute on Tuesday and Thursday from Kendall to Boca Raton.

One of my favorite quotes is "Hire the most amazing people you can. Communicate goals.  Turn them loose.  Profit."  - Sam Schillance, Box.  One of my rules of working at a job is to be surrounded by great engineers, then see how much they complain about my code.  This is by far why I love this company.  Again, It’s not the graffiti, nor the free food (which is delicious), nor the fact that I work remotely from Miami.  It’s the engineers that I work with.  When I started, I met a few great engineers.  People from my team are former Googlers, people who worked at Bloomberg, current Apache committers, and entrepreneurs.  Just a great set of interesting people who love to code and yet find a way to find a life after work - teachers, band players, great parents, rock climbers, etc.  For the past nine months, I’ve learn more than any other company in my professional career, both personally and technically.  Don’t get me wrong, it’s a very competitive company!  The bar is raised high the moment you are hired, and the expectations are tremendous, but the safety net of the team is why I have a smile on my face every time I come to work.  For example, there are five people that I always turn to in case I have any questions: Gabe, Alex, Tyler, Oliver, and Rob.  In my view, these guys composed the core of the technology of 3Ci.  They have a tons of experience, are highly innovated, smart, charismatic, and a great set of guys.  Together, I call them my G.A.T.O.R team and it’s such a pleasure working with them.

My final interview was with one of the founders and COO, Mark Smith.  One of his questions was, “What do you want to do in the future?”.  I told him that I wanted to eventually start my own company, learn Machine Learning,  and keep running MJUG and Miami JVM Meetup.  He said, “Awesome, we’ll help you”.  Done!  After that, I was asking “Where do I sign?"  Mark and Alex are by far the best leaders that I ever had.  They know when to help the team, and when to get out of their way.  If you worked for more than 10 years, then you’ll know that it’s hard to find a good company, even harder to find a good leader that could be a mentor.

Big Hairy Audacious Goals

Another huge incentive for me was to be able to tackle what James Collins calls, “Big Hairy Audacious Goals”.  Although I can’t say anything about the goals for the company, trust me, they are as big as they are interesting.  This is what motivates me.  The fact that I work with an awesome team tackling some really big problems, help set the path of pushing the envelop as much as we can.  Because of this, we look at other technologies and think outside the norm.  I believe that there is a challenge-to-great-developers matrix

.  In my experience, great engineers gravitate to hard challenges.  This is where I want to be.  I don’t want to work on another CRUD application (been there, done that, got the t-shirt!)  I believe that the best combination of retention of great engineers is to have great challenges for them to solve, have a great culture, and provide the best atmosphere for them.

I’ve always want to work for a company like 3Ci and I’m glad to be part of it.  It’s hard to find companies such as these in South Florida.  3Ci is committed to hire the best.  They are also very much focused on the culture.  The best way that I can describe its culture is using this quote, “When you combine a culture of discipline with an ethic of entrepreneurship, you get the magical alchemy of great performance" - Jim Collins, Good to Great.  I once read that you should choose a profession that you enjoy and that serves as many people as possible.  Focusing on serving others - not on building wealth.  Serve well and money will follow.  I’m glad that this year I was able to scratch that one from my “to-do” list.

Functional Thinking Video Review

I view new programming languages like president candidates, I don't trust them.  They believe that by being in office (projects), everything will be better.  When functional programming started its hype I watched from afar.  This was until I was working for a stock trading firm with lots of financial algorithms and lots of multithreaded application.  Before this gig, my languages of choice have been pure Java and Groovy. The world of Scala, Clojure, Haskell, and Erlang was just a bunch of noise. I was skeptical about this presentation, but I am a fan of Neal Ford so I decided to give it a shot.  Overall, I was very pleased with the content mainly because it did not focused on syntax, it focused on context! "Functional" is more a way of thinking than a tool set. For anyone to understand functional programming you need to understand the concepts, and Neal achieved this in his presentation.

 Neal points out the major advantages of using functional programming:

1. Language Evolution: all major languages are adding functional features. 
2. Results over steps: create optimized applications to solve a problem rather than using frameworks
3. Immutability: the freedom of not worrying about the state of the objects - "failure atomicity" 

Then, he elaborates a bit more on the subject matter. For example:

• First-class/higher-order functions 
• Pure Functions 
• Recursion 
• Strict Evaluation 

If you want to see more, check out the videos here or check this video for introduction.

Configure MTR in Mac

To configure MTR do the following:
First Install brew
Install MTR using the following commands:
Unfortunately, the configuration installs in the /usr/local/sbin
What I end up doing is removing the symbolic link and point it to my bin

Personal MBA Book Review

Just finished reading The Personal MBA: Master the art of business by Jorge Kaufman. I have an Executive MBA from the University of Miami (UM or "The U"), so I was very skeptical at the beginning. However, I really enjoyed the book. First of all, there is a lot of stuff that I learned during my MBA, but as he puts it towards the end of the book,

Educating yourself about anything is a Tao - there's no end to the process. The journey itself is the reward.

If you are the type of person that wants to learn more about business, I highly recommend it.  The book distilles a series amount of great books into one.  Here's what you learn:

• how businesses work
• how people work (chapter 6 -8)
• how systems work (chapter 9-11) 

You shouldn't expect:

• Manager and leadership overload. 
• Finance and accounting. 
• Financial intelligence for entrepreneurs 
• How to read a financial report 
• Quantitative analysis: thinking statistics, turning numbers into knowledge 

The one thing that I kept using while reading was a notebook and pen handy.  I also tried to review this every month.

I found it kind of sad that the book didn't covered any quantitative analysis in this analytic age, but I was happy that he covered how systems work.  This is the chapter that really resonated with me.  Here are my notes on the systems chapters.

Analyzing Systems

Deconstruction: the only way to analyze a complex system is by deconstructing it. "Deconstruction is the process of separating complex systems into the smallest possible sybsystems in order to understand how things work." You need to find the "ins" and "outs" of the system for you to understand it. Unable to understand complex systems, you need to decompose them into smaller systems for you to understand them.

Measurement: You need to measure the systems so you know if it's doing fine or not. "Measurement helps us avoid the absence blindness when analyzing systems. Remember: we have a hard time seeing things that aren't present. Measuring different parts of a system in operation helps to identify potential issues before they arise." One example is diabetes, a person needs to measure its blood glucose to know if it's too high or too low. A person cannot tell the level of glucose unless he/she measures it.

Key Performance Indicator (KPI): some measurements are better than others. Key performance indicator tell you exactly the status of your system. "Key performance indicators are measurements of the ciritical parts of a system. Measurements that don't help you make improvements to your system are worse than worthless: they are a waste of your limited attention and energy." Few questions the author used to identify business' KPI:

• Value Creation: how quickly is the system creating value? What is the current level of inflows?
• Marketing: how many people are paying attention to your offer? How many prospects are giving you permission to provide more information?
• Sales: how many prospects are becoming paying customers? What is the average customer's lifetime value?
• Value Delivery: how quickly can you server each customer? What is your current returns or complaints rate?
• Finance: what is your profit margin? How much purchasing power do you have? Are you financially sufficient?

Analytical Honesty: always look into data without discrimination of personal feeling. "Analytical honesty means measuring and analyzing the data you have dispassionately. Since humans are social creatures, we tend to care deeply about how other perceive us, which give us a natural incentive to make things look better than they actually are. If you purpose is to actually make things better, this tendency can get in the way of collecting accurate data and conducting useful analysis.

Sampling: is the process of taking at random a small percentage of the total output, then using it as a proxy for the entire system. If you ever had blood taken at the doctor's office, you'll have a good idead of what sampling entails. 

Margin of Error: this entails on the percentage of accuracy your system has based on tests. "Is an estimate of how much you can trust your conclusions from a given set of observed samples." When it comes to analytical confidence, more data is always better. 

Ratio: is a method of comparing two measurements against each other. By diving your results by your input, you can measure all sorts of useful relationships between different parts of your system. Here are some useful ratios to track:

• Return on promotions: for every $1 you spend in advertising, how much revenue do you collect?
• Profit from Employee: for every person you employ, how much profit does your business generate?
• Closing Ratio: for every prospect you serve, how many purchase?
• Returns/Complains Ratio: for every sale you make, how many choose to return or complain?

Typically: identifying a normal or typical value for some important measurement. There are four common methods of calculating a typical value: mean, median, mode, and midrange.

• mean: average
• median: sort the values in order of high to low, then finding the quantity of the data point in the middle of the range. Median are actually a specific form of analysis called a percentile: the median is the value that expresses the fiftieth percentile. By definition, 50% of the values in the set will be below the median.
• mode: is the value that occurs most frequently in a set of data. Modes are useful for finding clusters of data - a set can have multiple modes, which can alert you to potentially interesting interdependencies in the system that produced that data.
• midrange: is the value halfway between the highest and lowest data points i a set of values. To calculate the midrange, add the highest and lowest values, then divide by two. Midranges are best used for quick estimates - they're fast, and you only need to know two data points, but they can be easily skewed by outliers that are abnormally high or low - Bill Gate's bank balance.

Correlation and Causation: causation is a complete chain of cause and effect. Correlation is not causation. Just because you can here illegal doesn't make you a criminal. Causation is always more difficult to prove than correlation. When analyzing complex systems with many variables and interdependencies, it's often extremely difficult to find true causality. 

Norms: are measures that use historical data as a tool to provide context for current measurements. If you are selling Christmas ornaments, it's a waste to compare them Q4 with Q2. You should compare this Q4 with the previous Q4. 

Proxy: measures one quantity by measuring something else. Used with care, proxies can help you measure the measurable - just be sure your proxy is directly and highly correlated with the subject of interest.

Segmentation: is a technique that involves splitting a dataset into well-defined subgroups to add additional context. Finding out that last quarter's sales increased by 20% is good, but knowing that they were done by 80% of women is even better. There are three common ways to segment customer data: past performance, demographics, and psychographics.

• Past performance: segments customers by past known action. For example, you can segment customer sales data using previous sales data, comparing sales to new customers with sales to customers who have previously purchase from you. Lifetime value calculations are a form of segmentation by past performance.
• demographics segments customers by external personal characteristics. Personal information like age, gender, income, nationality, and location can help you determine which customers are your probable purchasers.
• psychographics: segments customers by internal psychological characteristics. Typically discovered via surveys, assessments, or focus groups.

Improving Systems:

Optimization: this is the process of maximizing the output of a system or minimizing a specific input the system requires to operate. Optimization typically revolves around the systems and processed behind your "key performance indicators", which measure the critical elements of the system as a whole. Improve your KPIs, and your system will perform better. 

Refactoring: the process of re-engineering the systems to improve efficiency without changing its output. The primary benefit of refactoring isn't improving the output - it's making the system itself faster or more efficient. 

The Critical Few: this is the 80/20 rule from Vilfredo Pareto.

For best results, focus on the critical inputs that produce most of the results you want.

Finding the inputs that produce the outputs you want, then make them the focus of your time and energy. Ruthlessly weed out the rest. 

Diminishing Return: after a certain point, having more of something can actually be detrimental. In the book the author explains about his work at P&G. At this company, he was the one in charge of analyzing the results of his advertising (tv spots). After time, the commercial will "wear out". That's the effect of diminishing return. "Optimize and refacgtor up to the point you start experiencing diminishing returns, then focus on doing something else".

Friction: Every business process has some amount of friction. The key is to identify areas where friction currently exists, then experiment with small improvements that will reduce the amount of friction in the system.

Automation: refers to a system or process that can operate without human intervention.

Find a way to automate your system, and you open the doors to scale via duplication and multiplication, improving your ability to create and deliver value to more paying customers.

The Paradox of Automation: the more efficient the automated system, the more crucial the contribution of the human operators of that system. When an error happens, operators need to identify and fix the situation quickly or shut the system down - otherwise, the automated system will continue multiplying the error. 

The Irony of Automation: the more reliable the system, the less human operators have to do, so the less they pay attention to the system while it's in operation. Remember the Mackworth Clock and vigilance studies conducted on British radar operators in WWII from our discussion on Novelty? Humans get bore extremely quickly if things stay the same, and the more reliable the system, the more things stay the same. 

Keep your automated system's operators mentally engaged, and they'll be far more likely to notice when errors inevitably occur. 

Standard Operating Procedure (SOP): is a predefined process used to complete a task or resolve a common issue. Business systems often include repetitive tasks or resolve a common issue. Well-defined standard operating procedures are useful because they reduce friction and minimize will power depletion. Instead of wasting valuable time and energy solving a problem that has already been solved many times before, a predefined SOP ensures that you spend less time thrashing and more time adding value. 

Don't let your standard operating procedure lapse into bureaucracy. Remember, the purpose of an SOP is to minimize the amount of time and effort it takes to complete a task or solve a problem effectively. If the SOP requires effort without providing value, it's friction. 

Checklist: a checklist is an externalized, predifined standard operating procedure for completing a specific task. Checklist will help you define a system for a process that hasn't yet been formalized. Second, using checklists as a normal part of working can help ensure that you don't forget to handle important steps that are easily overlooked when things get busy. 

Checklist can produce major improvements in your ability to do quality work, as well as your ability to delegate work effectively. By taking the time to explicitly describe and track your progress, you reduce the likelihood of major errors and oversights, as well as prevent willpower depletion associated with figuring out how to complete the same task over and over again. 

Cessation: is the choice to intentionally stop doing something that's counterproductive. In The One-Straw Revolution, Masanobu Fukuoka wrote about his experiments with natural farming, which mostly involved letting nature take its course and intervening as little as possible. Instead of trying to do too much, Fukuoka only did what was absolutely necessary. As a result, his fields were consistently among the most productive in the are. 

Cessation takes guts. It's often unpopular to unpalatable to do nothing even if doing nothing is actually the right solution. 

Resilience: what business needs is more turtles and fewer tigers. Turtles are nature's tank - they can eat different food, go through hibernation if times are tough, and shelter from an enemy if needed. Tigers depends on their strength, speed, and pray to live. If prey becomes scarce or they lose their hunting powers due to age or injury, death takes them quickly and mercilessly. This is why turtles live longer than tigers. 

Resilience is a massively underrated quality in business. Having the toughness and flexibility to handle anything life throws at you is a major asset that can save your skin.
What makes a business resilient:

• low (preferably zero) outstanding debt
• low overhead, fixed costs, and operating expenses
• substantial cash reserves for unexpected contingencies
• multiple independent product/industries/lines of business
• flexible workers/employees who can handle many responsibilities well
• no single points of failure
• fail-safes/backup systems for all core process

Planning for resilience as well as performance is the hallmark of good management.

Fail-safe: is a backup system design to prevent or allow recovery from a primary system failure. As much as possible never have a single critical point of failure. 

Stress testing: is the process of identifying the boundaries of a system by simulating specific environmental conditions. 

 
Scenario Planning: is the process of systematically constructing a series of hypothetical situations, then mentally simulating what you would do if they occurred. Most large business use scenario planning as the basis of a practice called "hedging": purchasing various forms of insurance to reduce the risk of unfavorable future events. 

 
Don't waste time trying to predict an unknowable future - construct the most likely scenarios and plan what you'll do if they occur, and you'll be prepared for whatever actually happens. 

The Middle Path: is the ever-changing balance point between too little and too much - just enough. 

The Experimental Mind-set: constant experimentation is the only way you can identify what will actually produce the result you desire. Often, the best (or only) way to learn things is to jump in and try.
You learn the most from what doesn't go well. As long as your mistakes don't kill you, paying attention to what doesn't work can give you useful information you can use to discover what does.

Using Deadbolt for Authorization in Your Play 2 Site With Scala

I needed security in my site. I needed a feature that would guarantee for only authorized users to go into some of the controllers (links) of my site. For non-registered users, I wanted to display a "non authorized" page so they could either login or register. I also needed for Play 2.1 using Scala 2.10. My search lead me to deadbolt 2 (D2). In this post I will cover the following:

• How to include deadbolt into your Play site
• Create a security service to validate registered users
• Send non-registered users to a "not authorized" page
• Add security to your controller
• How to validate registered users from the template

Include deadbolt into your Play site

The first thing that you need is to include the deadbolt plugin into your site. You need to include it inside your project/Build.scala. Here you will find that I added the play-plugin-mailer already, postgresql, and finally deadbolt. I had to include the resolvers for the application to work.

Add Security Service to Your Application

Before you implement the service, you need to create a subject. Subject is what determines a user in deadbolt. It also handles privileges such as roles and permissions. Below is the code for a User inside the app/models package:

Now, that we have a subject, we need to implement the DeadboltHandler to validate registered users/subjects and to send the non-register users to a "non-register" page. The main application that takes care of user validation is the getSubject.

Here the code tries to get the the username from the HTTP session, and in case there is a user, return a subject (User) with that session name. Otherwise, return a "None". When returning None, Deadbolt automatically knows that this is not a valid/registered user.

Send Non-Registerd users to a "Non-Registered" Page

For those users that are not registered (None Subject), the "onAuthFailure" will take effect.

Below is the code inside the app/security package.

Add Security to the Controller

Now, that the DeadboltHandler is implemented, you have to make some decisions based on the business rules of your site. For example, if you have an Contact Directory page where only registered users could see it, you need to assure that there is a Subject (registered user) present.

Noticed that I am also passing a new MyDeadboltHandler to the page. This is because I also need to implement some business rules inside the template. In this site, I needed to show a "Login" link for those non-registered users or display a "Contact Directory" and a "Logout" link for those authenticated users. Below is my navigation template.

Inside the "subjectNotPresent" we will handle the case when the user is not logged in. Whereas, in the subjectPresent we will show the Logout and the Contact Directory link pages.

For those controllers that doesn't require the a subject to be present, I still had to pass the implemented deadbolt handler because it had to be in every one of my pages. This is to validate if the user is authenticated.