Speed Reading

I always considered speed reading as a major way to improve one's overall performance. Especially in brain related activities.
So I read this book and here is a brief outline of it:

1. In a world that speeds up all the time reading faster without loosing meaningful information is vital.
2. There must be a goal (reading speed increase, ratio of speed to understanding) to aim and a time span to achieve it. 
3. Speed Reading Techniques:

• Reading the table of contents
• Meta-Guiding (pointing what to read next with you finger)
• Visualization (not a standalone technique still very helpful skill)
• Keyword search
• Chunk Reading
• Skimming (if you want to grasp the overall idea)
• Scanning (if you have an idea to scan for)

Gymnastics to widen up your sight area:

• Fixate your sight at a dot in the middle area of a text. Try to read from outer areas with your sight.
• Thumb-to-thumb glancing.
• Eye Writing
• Hooded Eyes
• Eye Squeezes

Exercises to increase your comprehension:

• Self-assessment
• Questionnaires, crossword puzzles
• Meta Cognition
• Extensive learning
• Communicate
• Contemplate

Other exercises:

• Push - up
• Push - down
• Alarm clock reading
• Timed reading
• 3-2-1 Drilled
• Chunks reding
• Speed Reading Comprehension tests

Additional considerations

1. Calming environment: light, noise ratio, smells
2. Focus: low level of distraction
3. Physical Exercise
4. Bad Food
5. Good Food
6. Sleep

Also discussed your tips to improve and fix major issues standing in your way and the overall benefits of speed reading.

I liked the book overall. It's a concise recap of good old technique with some more examples and ways to work it out.

Is AI a good or a bad thing

The history of the human race is a history of love and warfare.

A lot of things have been developed with no other application but fighting one alike.
We've got a whole lot of highly technological things such as nuclear submarines, jet carriers, interceptors, tanks and so on that can not really do anything but war.
Now, in regard to the most stunning examples of warfare I do want to give you some rough numbers on mortalities in the world wars:

World War I - 15,486,153 to 18,423,970

World War II - 70,000,000  to 85,000,000
It's not just numbers. It's all people. Someone's fathers, sons, mothers and daughters. Every single one was a person with his own history, aspirations and ideas. Lots of those people died not for themselves but for the countries, families and nations they were part of.

Now, with artificial intelligence coming to the scene I am considering a few major transformations of the world we know now:

• AI is to push a lot of people out of their professions. Today it sounds like only proles are at risk, but I'm quite confident that the next aim is white collars. IBM Watson can already diagnose patients better than the majority of MDs and considering more facts such as genomics. So in a medium term there's going to be a lot of people devastated by being pushed off from work they know without a plan to handle it. Consequences of this misfortune are not hard to imagine.
• AI is to set the bar high in the quality of care / farming / etc. But it will be very hard for people to catch up with all the knowledge computers can process on a factor of magnitude faster than any human being. And so lots of young professionals will simply give up on professions without even trying. The overall degradation of the educated people will commence across the globe.
• AI (at least the way it looks now) will learn from the examples provided by humans. Not only the results of the learning can be askew and we will get a nazzi AI but it will not really introduce any creative ways of doing things. And the society driven by AI will head towards promoting mediocracy. There will be no trial and failure loop or inventions made by failure. Tell me how many times great things started for you while thinking of something on a piece of napkin in a bar?

Now on the existential threat end

• If a passenger jet is hit by a missile, is it the fault of the missle or the one who launched it? Now, all the missiles of the world nuclear ones included are just a scratch on the surface what AI can become in a matter of days if not hours once it is born. Considering that AI learns so much faster than any of the best brains on the planet ever could will we be able to stop it if something goes wrong? 
• AI is tought from the examples provided only by us with our fallacies and weaknesses. Will it be fallable by design then?
• Can anybody give me a rational explanation why we need to exist on the Earth? If we don't have it, why would you think AI invented by us should have one?

I think the mejor fallacy of gAI is it has no emotions and empathy to human beings. If built on a pure rational basis I don't see a good reason for it to treat us as necessary addition to its wellbeing. Thus I think we need not only how to teach it learn, but how to teach it feel as well.

Multithreaded programming in layman's terms

Multithreading is a software concept that allows several programs run in parallel. While getting my head around it and talking to lots of folks about it I conveyed that we can compare multithreading with the real world.
Let's map concepts from the world of threading to the real world concepts.
OS is an enterprise. There're many different departments working at the same time. They can interact to each other in some way but it's not necessary.
Processes are rooms for the employees. Effectively rooms do not do anything. They are just compartments for the employees to work in.
Threads are employees. They are the ones doing any job we have whether it's designing a new marketing strategy or wiping out the streets.
Every enterprise can create rooms when it has a project to work on and assign employees to it. Usually you start with one thread per process and create more as you need.
Now, synchronization is a concept that can take a while to grasp. It is a way to allow different threads to interact with a shared resource.

Let's assume we have a single bathroom. If we were to allow multiple folks inside it would be hard to cope with the aftermath. So there can be only one person at a time. And that's what we achieve with synchronization. The simplest synchronization mechanism is mutual exclusion. Effectively it's closing the door from the inside once you're in. And nobody but you can unlock it.

Now there's another synchronization concept also described by Dijkstra called semaphore. It's a mutex with a counter assigned to it. Let's assume we have a bathroom with four standalone rooms. Once all the rooms are occupied the entry automatically gets locked out. Once there's a vacancy the door gets open again.

So far it's the simplest metaphor I came up wth. But it works while explaining it to newbies.

Why Lean

Why does it even matter?
Because we, as people building software, usually forget that the piece of software we're building is not the end goal. The profits, public awareness, social growth is. And the tool is not the driver of the business. You can cook delicious pastries in an ancient oven or in a high-end one. It's not going to make it better if you have screwed up with the recipe.
The recipe.
Figure out what is important. What are the most relevant flows for the customer. Which ones give you the highest conversion. Get metrics for the operation. How often do you need to click 10 times to get a report of one variable? How often does a human have to check tire pressure? What is the time waste? What is the effort to fix it? Count both in hours and dollars spent. Can we automate the process? Where does deficiency come from? Can we just remove the inefficiency? Can we make it semi-automated?
Improve if the ROI is high. Act on it! Do one thing at a time.
Validate what the result metrics are. Did you actually improve the process? Did you eliminate the waste? Does it work better now? Did customers appreciate the experience?
Apply the same approach to new products. Come up with the idea. Try it out. Make the implementation as simple as possible. Google search page still has only one input field and two buttons. But it's probably the most visited web site in the world. See if people buy into the idea. Get metrics around it. Groom it based on the metrics you have. Don't make the customer wait too long.
Measure what you do and what is the outcome of every feature you deliver. Save your time by not doing low-value frictions. Do high-value things. Now!

Does Java lack auto generated properties?

Is Java that bad in compliance to OOP pillars?

I had a few conversations with OOP developers in my community just recently and often it sounds like people want to have some new features as a part of the programming language they are using.

So we have auto properties as a part of C# 3.0, attribute accessors in Ruby and simple old getAttribute() methods in Java.

Now, we often expose internal state of the object to the outside world which I don't think is a good pattern for most cases. And as far as we're tired of writing those getMethods and setMethods all over we're trying to increase the productivity while writing those. Without consideration that most business actions affect a few properties at a time.

My take is we should expose methods that represent a business action like add two bags of potatoes to my shopping cart. The number of items, item type, SKU is integral for the action. 

So what if we change the process of adding an item to the shopping cart? For instance now we need to change the last update date of the shopping cart object every time we add something to it. If we were to encapsulate the change logic around the shopping cart object we would get a one line code change. Otherwise we are to change all the consumers of the object. Which I consider is a code duplication. Bad smell it is.

In this case I think languages such as Ruby and C# provide you both the toolset and the responsibility to make decisions on how to implement the solution. Java on the other hand gives you the only way to implement it property. But relies on the tools (all Java IDEs can generate property stubs) to make the development productive.

DDD summary book

For those lazy or just struggling to find enough time for reading the full version of the DDD book find out this prune summary. The book is definitely worth reading for software engineers and architects. It describes the basics of modeling and how to model business processes with business goals in the first place. I consider it to be on the same shelf as Martin Fowler's book PEAA.

Tiny cucumber test issue

I was working on a project the other day, and out of the blue there was a failing test which was not failing before.

The cucumber test reads as follows:

Scenario: Index action (No filtering)
Given the following persons with time_submitted exist:

id	email	name	time_submitted
1	person1@example.com	person1	1347978729
2	person2@example.com	person2	1346802773

When I visit "/index.json"
Then the JSON response should have 2 persons
And the JSON response at row 0:time_since_last_update should be approximately 3 week(s) ago
And the JSON response at row 1:time_since_last_update should be approximately 1 month(s) ago

The issue here is that we rely on the hardcoded value of the time submitted. And when we run out of the timeframe window the test starts failing.

To resolve the issue we need to come up with some dynamically evaluated value. Certainly, my initial attempt was to update the number with 2.weeks.ago. The test failed one more time claiming that the object is a string. That made me poke around the documentation a little bit. And what I came up is method send which allows you to execute method by name.

And so after refactoring my test input table looks so:

Scenario: Index action (No filtering)

Given the following persons with time_submitted exist:

id	email	name	time_submitted	period
1	person1@example.com	person1	3	weeks
2	person2@example.com	person2	1	months

When I visit "/index.json"

Then the JSON response should have 2 persons

And the JSON response at row 0:time_since_last_update should be approximately 3 week(s) ago

And the JSON response at row 1:time_since_last_update should be approximately 1 month(s) ago

and the code behind looks like

Given /the following persons with time_submitted exist:/ do |table|

  table.hashes.each do |hash|

    value = PersonAttributeRecord.new

    period = hash['period']

    number = hash['time_submitted'].to_i

// Here comes the magic

    value.submitted = number.send(period).ago

    Person.create ({:id => hash['id'], :email => hash['email'], :name => hash['name'], :time_submitted_db => value})

  end

end

So we parse the number from the table. And execute either months or weeks method (or whatever method we need) on it. And then subtract it from the current date.

That's it. Sometimes those tiny little tricks help a lot!

PS: Thanks to Kory Kraft who put a lot of effort into this little thing as well