In my time playing around with neo4j I’ve run into a problem a few times where I executed a query using the web console (usually accessible @ http://localhost:7474/webadmin/#/console/) and have got absolutely no response.

I noticed a similar thing today when Rickard and I were having a look at why a Lucene index query wasn’t behaving as we expected.

I setup some data in a neo4j database using neography with the following code:

require 'neography'
 
@neo = Neography::Rest.new
 
@neo.create_node_index("Id_Index", "exact", "lucene")
 
node1 = @neo.create_node("Hour" => 1, "name" => "Max")
node2 = @neo.create_node("Hour" => 2, "name" => "Mark")
node3 = @neo.create_node("Hour" => 3, "name" => "Rickard")
 
@neo.add_node_to_index("Id_Index", "Hour", 1, node1)
@neo.add_node_to_index("Id_Index", "Hour", 2, node2) 
@neo.add_node_to_index("Id_Index", "Hour", 3, node3)

I then ran the following query which I was expecting to return all the nodes:

start hour=node:Id_Index("Hour:[00 TO 02] or Hour:[03 TO 05]") RETURN hour

Instead it returned nothing and I couldn’t see anything being logged either.

Rickard pointed out was because the exception is only returned to the API caller and that it would be better to run the query from the Data Browser which is typically accessible from http://localhost:7474/webadmin/#/data/search/

If we run the query from there then we can see what’s going wrong:

BadInputException
 
StackTrace:
org.neo4j.server.rest.repr.RepresentationExceptionHandlingIterable.exceptionOnHasNext(RepresentationExceptionHandlingIterable.java:50)
org.neo4j.helpers.collection.ExceptionHandlingIterable$1.hasNext(ExceptionHandlingIterable.java:60)
org.neo4j.helpers.collection.IteratorWrapper.hasNext(IteratorWrapper.java:42)
org.neo4j.server.rest.repr.ListRepresentation.serialize(ListRepresentation.java:58)
org.neo4j.server.rest.repr.Serializer.serialize(Serializer.java:75)
org.neo4j.server.rest.repr.MappingSerializer.putList(MappingSerializer.java:61)
org.neo4j.server.rest.repr.CypherResultRepresentation.serialize(CypherResultRepresentation.java:57)
org.neo4j.server.rest.repr.MappingRepresentation.serialize(MappingRepresentation.java:42)
org.neo4j.server.rest.repr.OutputFormat.assemble(OutputFormat.java:179)
org.neo4j.server.rest.repr.OutputFormat.formatRepresentation(OutputFormat.java:131)
org.neo4j.server.rest.repr.OutputFormat.response(OutputFormat.java:117)
org.neo4j.server.rest.repr.OutputFormat.ok(OutputFormat.java:55)
org.neo4j.server.rest.web.CypherService.cypher(CypherService.java:94)
java.lang.reflect.Method.invoke(Method.java:597)

There seemed to be some strangeness going on with how Lucene handles the query when a default search field isn’t provided but we noticed that it behaved as expected if we didn’t use an OR since Lucene has an implicit OR between statements anyway.

start hour=node:Id_Index("Hour:[00 TO 02] Hour:[03 TO 05]") RETURN hour

Either way, the lesson for me was if the console isn’t giving a result run the query in the data browser to work out what’s going wrong!

I’ve started work on some new videos and this time it’s all about Agile Estimating, Planning and Contracts. This is the obvious next step having completed Scrum101, and I’m apply some of the lesson that I learnt. I’ve recorded about an hours worth of audio and, at this moment, it feels like I’m about a third of the way through. I think I’ll have about 3 hours worth of material before I’m done.

As an exercise to understand how I want this new material to look and feel, I took the very first topic (Absolute Estimating vs. Relative Estimating) and created a presentation to go along with the audio. This is my first draft, with an unprocessed (for noise reduction or effects) audio. I think it’s a big improvement from what I’ve done before.

I’d love to hear you thoughts and opinions, so feel free to leave a comment below.

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

“We have always had as much time as we have ever had. No more, no less.” – Anon.

In the modern life of daily hustle and bustle, of striving, failing and achieving, we are prone to forget vital things. One of them is this: Time is the most precious asset we have.

Imagine life as a finite timebox. We have as much of it as we have ever had. When the bell tolls, the size of the timebox isn’t open for negotiation.

Instead of thinking yourself time-poor, think of yourself as time-rich. Distinguish between a want and a need. Now how would you choose to invest life time?

And if you haven’t already, see “The Odd Story of Timothy Green“. It’s a story about life, love and living. It’ll really make you think.

To do great things, it helps to study people that do great things and show us better ways to do things.  It helps us build our reference library of what’s possible and it helps inspire us to new levels of success.

Most importantly, it expands our capabilities.

Chalene Johnson is a powerhouse when it comes to personal development.   She continuously pushes herself, while expanding and exploring what’s possible physically, mentally. and emotionally.   She’s a unique blend of entrepreneur, physical fitness expert, choreographer, author, life changer, and motivational speaker … and we can learn a lot from her approach.

I wrote up 27 lessons from Chalene Johson, but my favorite lesson is actually Lesson #7 – Success isn’t magic, it’s a method:

Chalene says, “It’s NOT luck — it’s KNOW HOW. There is a formula for everything.”   You have to study the people that have the results that you want.   Learn from their formula.   Study what made them successful.  If you can find the proven practices and the methods that work, you’ll speed up your success, and you’ll avoid the dead-ends.   Finding a formula helps you establish and practices routines that will help you get better and better over time.

Personally, I’ve found this to be true time and time again.  Whenever I got stuck, it was my strategy or approach.  I just didn’t know the right formula or who to model from.  There’s always a recipe.  One of the most important things I learned on the Microsoft patterns & practices team is that if you look to the right sources, you’ll find the proven practices or the patterns that really work, even if it’s not well-known (in fact, part of our job on the Microsoft patterns & practices team was really to share and scale this knowledge more broadly.)

I’ve shared my personal rapid results formula before in The Way of Success, and it helps elaborate on how to model success in a more effective way.  As Tony Robbins says, success leaves clues.  We just need to be good students of possibility to find them and apply them.

Even if you’re not into working out, I think you'll enjoy lessons from Chalene Johnson on personal development, productivity, motivation, and more.

1. The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scale.  It is illustrated in the big picture.

As Scrum is to the Agile team, SAFe is to the Agile enterprise.

2. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale.  It is field-tested and enterprise-friendly.
3. SAFe is the brainchild of Dean Leffingwell.

As Ken Schwaber and Jeff Sutherland are to Scrum,
Dean Leffingwell is to SAFe.

4. SAFe is based on Lean and Agile principles.
5. There are three levels in SAFe:
   * Team
   * Program
   * Portfolio

At the Team Level:

6. Scrum with XP engineering practices are used.
7. Design/Build/Test (DBT) teams deliver working, fully tested software every two weeks.  There are five to nine members of each team.
8. Rally’s weekly TeamStart webinar series covers the basic practices at the team level.

At the Program Level:

9. SAFe defines an Agile Release Train (ART).  As iteration is to team, train is to program.
10. The ART (or train) is the primary vehicle for value delivery at the program level.  It delivers a value stream for the organization.
11. SAFe is three letter acronym (TLA) heaven – DBT, ART, RTE, PSI, NFR, RMT and I&A!
12. Between 5 and 10 teams work together on a train.  They synchronize their release boundaries and their iteration boundaries.
13. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI).  A demo and inspect and adapt sessions are held.  Planning begins for the next PSI.
14. PSIs provide a steady cadence for the development cycle.  They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.
15. New program level roles are defined
    * System Team
    * Product Manager
    * System Architect
    * Release Train Engineer (RTE)
    * UX and Shared Resources (e.g., security, DBA)
    * Release Management Team
16. In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles.  If they have deep domain expertise, they are likely to fill the Product Manager role.  If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.
17. SAFe defines a Scaled Agilist (SA) certification program for executives, managers, architects and change agents responsible for leading SAFe implementations.  Rally provides regular public and private Leading SAFe certification classes.
18. SAFe makes a distinction between content (what the system does) and design (how the system does it).  There is separate “authority” for content and design.
19. The Product Manager (Program Manager) has content authority at the program level.  She defines and prioritizes the program backlog.
20. SAFe defines an artifact hierarchy of Epics – Features – User Stories.  The program backlog is a prioritized list of features.  Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level.  Features decompose to User Stories which flow to Team-level backlogs.
21. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.
22. The System Architect has design authority at the program level.  He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met.  He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.
23. The UX Designer(s) provides UI design, UX guidelines and design elements for the teams.  In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.
24. The Release Train Engineer (RTE) is the Uber-ScrumMaster.
25. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.
26. Rally’s monthly Program webinar series provides an overview of Scaling Agile Programs with SAFe.

At the Portfolio Level:

27. PPM has a central role in Strategy, Investment Funding, Program Management and Governance.
28. Investment Themes drive budget allocations.
29. Themes are done as part of the budgeting process with a lifespan of 6-12 months.
30. Portfolio philosophy is centralized strategy with local execution.
31. Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes.
32. There are business epics (customer-facing) and architectural epics (technology solutions).
33. Business and architectural epics are managed in parallel Kanban systems.
34. Objective metrics support IT governance and continuous improvement.
35. Enterprise architecture is a first class citizen.  The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.
36. SAFe patterns provide a transformation roadmap.

  Legacy Approach Lean-Agile Pattern

#1

Centralized control

Decentralized decision-making

#2

Project overload

Continuous value flow

#3

Detailed project plans

Lightweight business cases

#4

Centralized annual planning

Decentralized, rolling wave planning

#5

Work breakdown structures

Agile estimating and planning

#6

Project-based funding

Agile Release Trains

#7

Projects and PMBOK

Self-managing teams and programs

#8

Waterfall milestones

Objective, fact-based measures and milestones.

Table above reproduced with permission of Leffingwell LLC and Scaled Agile Inc

37. Rally’s monthly Portfolio webinar series provides guidance on Lean | Agile approaches to PPM.

Adoption

38. Adoption focuses on identifying a value stream.  A value stream is a sequence of activities intended to produce a consistent set of deliverables of value to customers.  Value streams are realized via an Agile Release Train (ART).
39. SAFe poses questions to help identify value streams (ARTs):
    * What program might adopt the new process the fastest?
    * Which executives are ready for a transition?
    * What are the geographical locations and how are the team members distributed?
    * What programs are the most challenged, or represent the biggest opportunities?
40. When you identify a value stream, you go “All In” and “All at Once” for that train.
41. Rally is an SAI Gold Partner.  Rally’s cloud-based solutions for managing the Agile development lifecycle directly support SAFe.  Read two independent analyst reports that show why “Rally Software continues its leadership in Agile/Lean.[1]”

[1] The Forrester Wave™: Application Life-Cycle Management, Q4 2012

.content td { padding: 2px 6px; } ol li { margin-bottom: 13px !important; } .safe-table th { background: #444444; font-size: 13px; color: #fff; border: 0; padding: 8px 0 0 8px; } .safe-table td { padding: 11px; background: #f4f4f4; border-top: 3px solid #fff; border-left: 3px solid #fff; } .safe-table td.first_col { border: 3px solid #fff; } .safe-table td { font-size: 13px; color: #444; margin-bottom: 8px } .safe-table td p { margin-bottom: 3px; } Rob Pinna

Navaneeth KN

In this blog post, I will explain another useful example of Twist's customized HTML reports. Usually test scenarios are associated with story cards. Twist simplifies this by allowing scenarios to be tagged to stories.

Thumbnail: 

read more

Countdown: 17 days until RallyON!  As we get closer to the event, we are knee-deep in content (and planning a welcome reception that will knock your socks off). We're refining the sessions and how they map to our overall themes of people, practice, and technology. This year's conference adds a new focus on Rally's platform, and how to optimize up and across the organization.

People - What makes an Agile leader different? What kinds of trade-offs are involved in their decision-making? Find out as Rally's Tim Miller and Christopher Avery explore what it means to consciously lead an Agile organization.  Also find out Jean Tabaka's "secret sauce" that Agile heroes use to keep their world in peace and deliver at scale.

Practice - One of our customers is presenting "Beyond Swarm Soccer," and the name says it all. Are we all chasing the ball, or do we work in concert across the field? Also, as Agile practitioners, how do you know when you're getting better? Applying extensive research, we've identified the Seven Deadly Sins of Agile Measurement, and will discuss which metrics matter.

Technology - We're taking a technical deep-dive this year by sharing lessons learned from both our customers and our own use. Sessions include product development using a build-measure-learn process, creating the most useful and used dashboards, and managing complex QA and test automation.  Our own engineers take center stage to discuss Rally's approach to building Lean product experiments and how we apply that to our product roadmaps.

There are too many great sessions to choose from, so bring a colleague -- or seven -- to share the learning.  We’ll see you next month in Boulder.  

Rally Software

Roy van de Water and Clayton Lengel-Zigich discuss:

• Why teams revisit situations
• Disclosing what you know
• Decider Protocol

The length of a Sprint determines how quickly a Scrum Team can “inspect and adapt” to changing circumstances and learning.  Scrum, as a tool for product development, sets an upper limit to the duration of a Sprint.  In other words, Scrum sets a minimum for the frequency of the inspect and adapt cycle.  This ensures that teams using Scrum get at least a certain minimum benefit.  Scrum does not set a maximum frequency (minimum Sprint length).  If a team has a five-week (or longer) Sprint, the benefits from Scrum rapidly drop off.  In particular, you dramatically increase risks associated with short term planning, responding to change, team development, windows of business opportunity, and error detection.  Having a cycle longer than four weeks is not Scrum and a team with such a cycle length should not claim to be using Scrum.

Building a taskboard using a laser guide

Here’s a high tech and original way of building a physical taskboard. (source: Agilar team @ Belgacom)

 

Last week Sam and I visited Durban to do some Scrum training. We were invited to join Chillisoft on Monday afternoon for their ‘Intention Practice’. Always keen to see how others improve themselves, we joined them eagerly.

Every Monday from 3pm to 6pm, Chillisoft have Intentional Practice. They sometimes invite customers or other developers to join them, and try to do something different each time. The session we joined was focused on the string kata and pairing practice. Here is how it was structured.

Everyone met at 3pm and Chris and Peter described the plan for the afternoon. The structure was as follows:

Round 1: Find a partner and do the string kata as a pair, in any language you like. Try to get as far as you can in 30 minutes. The focus for round 1 was on pairing, most people did ping pong pairing for this round.

After 30 minutes we got back together and discussed what people had learned.

Round 2: Find a new partner. Delete whatever you did before and start the string kata over again. The challenge for round 2 was to not use a mouse, so people would learn to use shortcut keys.

After 30 minutes we got back together and discussed what people had learned.

Round 3: Find a new partner. Delete whatever you did before and start the string kata over again. The challenge for round 3 was that every 10 minutes, we would switch workstations and pick up where the previous pair had left off. Round 3 was 40 minutes so we switched 4 times. This was even more fun since one pair was doing the kata in Javascript and everyone else was using C#.

After the third round, we did a final debrief. Sam and I played the Ball points games with the whole team and then we all had dinner together.

Here is what I learned.

Doing a kata over and over again with different people led to a good discussion on emergent design. i.e. what is the best point to refactor into 2 different classes for parsing and adding.

This is a great way to experience TDD done right, and makes it much more likely that people will do it in their day jobs.

Many companies I know have time each week for growth and learning, but this is seldom well structured. Having a format like this meant people used the time really well. I’d highly recommend bringing some structure into sessions like this if you do them today.

I was once again reminded of the freedom TDD brings to just do what you need right now and worry about complexity later. It really helps make complex problems easier to tackle, one bite at a time.

Pairing is an excellent technique to bring people up to speed FAST. I hadn’t coded in 12 years, and I was able to contribute within 10 minutes.

Sessions like this are a great way to expose people to how you work. Chillisoft invited someone who they were thinking of hiring to attend. A great way for both parties to get a feel for each other in an environment that’s more relaxed than an interview.

Thanks Chillisoft for inviting us. It was loads of fun and learning for us. Plus we love the t-shirts

 

 

 

Why firing brilliant assholes is required to build a great engineering culture

 

Mein Blog besteht dieses Mal mit Absicht nur aus dieser Frage. Ich möchte damit zum Nachdenken anregen: Was passiert, wenn man Konflikte oder andere Probleme einfach „beseitigt“, anstatt genauer hinzuschauen, was dahintersteckt?

Hätte es ipad, ipod und iphone gegeben, wenn der geniale, aber auch exzentrische Jobs seine Teams nicht zu Höchstleistungen getrieben hätte? Würde es heute Smartphones geben und Tablets? Ob wir das alles brauchen, ist eine andere Frage. Ich jedenfalls liebe mein ipad und ich bin keine Apple-Jüngerin. Es ist etwas Besonderes, es in der Hand zu haben, fast ein Handschmeichler. Auch mein iphone ist ein haptisches Vergnügen und die App Integration von Twitter, Facebook & Co macht richtig Spaß. Ich habe auch Android-Tablets und Smartphones, aber Apple ist irgendwie besonders.

Hätte jemand anderer Tablets und Smartphones erfunden? Ich weiß es nicht. Fakt ist, dass die Produkte von Apple zumindestens meine Welt verändert haben und ich mich frage, was gewesen wäre, wenn jemand das “Ekelpaket” Steve Jobs einfach rausgeworfen hätte.

Just think about it.

Related posts:

1. Über das Schreiben | Leidenschaft
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben

Continuing with the 100 Things You Must Know to Be Effective In Software Development While adding value to the customer is the ultimate goal, there is more than customer value. There are actually at least five different types of business value: knowing what will be of value to the customer knowing how to build this building this deploying this value so it is consumed by the customer being...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Today was the first day of the Google IO conference in San Francisco. I was lucky enough to be able to attend so I can share some (personal) highlights of the day.

In the keynote Google showed some of their latest developments:
It is now possible to upload a batch of pictures to your online storage and let Google decide which are the best ones to keep. For instance when you’ve been on holiday and have taken 600 pictures, too many to show to anybody, Google can propose a selection after doing some intelligent analysis:
It can filter pictures if they are dupicates or if they are unclear. But it also recognizes if pictures contain some of your (Google+) relations, which would make them more interesting. Even more cool: with the help of some machine learning and a lot of training, Google can now estimate if a picture is pretty or not.
Another cool feature: Google will recognize if you have multiple pictures of the same person in the same scene. Based on some intrapolation algorithm, it can generate new pictures in that scene. Some examples were shown and they were actually really good.

Voice recognition was added Chrome (desktop and Chromebook only) so you can give spoken commands to let it do searches. Not really new, but what makes it special is that integration was added with Google Knowledge Tree, a giant graph database which contains semantic relations between entities.
What this means is that Chrome might understand what you mean when you say something like: “Send Misja an e-mail with the shortest route from here to Amsterdam”. This does require that Misja is one of your Google+ contacts. Chrome will infer that ‘here’ refers to your current location.

And there were many more announcements. You can see the full keynote speech here.

In the afternoon there was a choice of about 60 different presentations. Obviously too many to watch or to describe. Here are a few brief highlights:

Google has added App Script support to Google Forms.
App Script support was already present in Gmail and Google Sheets and it enables you to write macro’s or other logic in Javascript. The Javascript can access and manipulate the document you are working on, it can use all Google Api’s and connect to databases.
Now it can also be used in Google Forms. Quite useful if you want to add form validation for instance.
You can try it out here

Google Compute Engine, Google’s cloud service, has gotten some useful pricing options for small businesses. The cheapest one can host your application already for less than 2 cents per hour. There’s not much use for buying your own server anymore if cloud computing becomes so cheap ..

Not picking on an API in particular, but…wait, yes I am. Octopus (an awesome product) has a proposed API on GitHub, and one of the things it describes is how to deal with the fact that the backend is built on top of Raven DB, where eventual consistency its default mode for index results.

In it, the proposal includes an “IsStale” flag on the collection, as well as on the query itself, so you could do something like:

GET /api/environments?nonstale=true

Or similar. This presents a rather weird choice to the end user of the API – consistency as a choice, not on mutating operations (PUT/POST/DELETE) but on idempotent GET operations. I presume that this will use the “WaitForNonStaleResults” behavior of RavenDB – but this isn’t really something I’d expect to directly expose to clients.

Without directly exposing our persistence mechanism to our clients (i.e., what if we switched to SQL Server? Redis as a write-through cache to MondoDB? and so on), we have a number of options of dealing with eventual consistency in our REST APIs.

Option 1: Do nothing

The easiest approach for our API is to simply not care. Non-stale results should only really appear when we’re dealing with queries and collections – if you’re dealing with stale resources from GET actions directly against a resource, you’ve really got a weird interaction model.

Looking at some other APIs, like Netflix or GitHub or Trello, you don’t really see any option for influencing the consistency choice on a read.

So we could just ignore it. This is what a lot of APIs do, accept the POST/PUT/DELETE, and make sure that my resource itself is affected correctly. If I do a DELETE /users/jbogard and then a GET /users/jbogard, I expect a 404. But if I query users or search them, then I might not expect those results to be reflected in that model. I can be explicit in this by having search be a completely separate set of resources/entry point (i.e. /search?entity=users&name=jbogard), so it’s completely explicit that search/query is different than interacting with resources.

This is similar to how a library with a card catalog might work. Do I synchronize the activity of checking out a book with checking the catalog? Or might someone have grabbed the book from when I checked the card catalog? Or do I have someone hold the card while checking out a book?

What I don’t do is allow a person looking for a book to either be disappointed OR have the choice of yelling out to everyone in the library, “DOES ANYONE HAVE THIS BOOK OR IS OTHERWISE WANTING TO CHECK THIS BOOK OUT”. I fix my interaction model and just be up front about it.

Option 2: Provide feedback on consistency results

Instead of just punting on whether or not the collection/query is stale, we might provide that as feedback. We could return dates of last update, things like “results as of mm/dd/yyyy”. We often do this on printable reports so that when people print a report (and it is now preeeeeetty much as stale as it gets), we can include a timestamp of when it was printed so that anyone looking at it is informed of how fresh the data is.

Just a tidbit of information to the end user to let them know if their results are up to date or not. If the client made a mutating operation, they can compare the date of this mutation with the date on the query results to make a simple decision to query again, or just move on as planned. Again, the power is in the client not to affect how we query, but what decisions they can make.

Option 3: Return a 202 ACCEPTED status

If we really want to model an asynchronous operation in our REST API, we can look to the HTTP status codes to communicate this explicitly to our clients. We do this in a couple of places where processing is too expensive in the context of a request, so we return a 202 to let clients know that “we got your request, but it’s not getting processed at this moment.” The description from the W3C reads:

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

We can return a pointer to an indication of the current status, or some estimate of completion. But we’re being 100% up front that your request is processed asynchronously.

This is similar to any long-running transaction. You place an order at a fast-food restaurant, and are given a correlation identifier that represents your order. You can come back and ask the status of your order at any time. But the cashier certainly doesn’t cook our order while we’re standing in line!
Option 4: Write-through cache

If these operations are expected to succeed (or we verify that the transactional write has succeeded), we can do a simple trick that a lot of high-volume websites do. If we don’t have an AP-system like Dynamo (choosing availability and partitionability over consistency), we might choose consistency instead. To do so, we can cache index results, and write our updated value to that store along with our regular persistent store.

It’s not the most exciting of options, but if we know that writes are much less frequent than reads (and we’re not partitioning, i.e. we pick CA of CAP), then it’s not too far-fetched to write to both our cache and our document store.

Of course, if this is all to force us to bypass our consistency model of the database we’ve chosen, it’s a lot of work. But still, it’s an option nonetheless.

Option 5: Choose a database that matches our consistency needs

If we don’t like the consistency model that our database provides, or we feel like we want to allow clients to choose a consistency model, we might view this as a case where we’ve simply chosen the wrong model. If clients NEED consistency, why not pick something that gives that to them? Or don’t allow them to choose.

This would be like, on writes, allowing clients that interact with a database that uses a relational model to also indicate the isolation level on writes. That’s something that should really be encapsulated by the operation, and made with SLAs and contracts about the behavior.

Conclusion

We have a lot of options here, and all are valid in some scenarios. In each example, we’ve chosen a consistency model that matches our needs, rather than have a compromised consistency model exposed from our database of choice. Before Amazon put out their Dynamo paper, it’s not like us as users of the website knew that this storage system existed in the back end. It was encapsulated. The most we could do was “Ctrl+F5” to force a request back to their servers, but that still had no real guarantees.

Instead of letting our database leak its consistency model to our API, it’s better to choose a model that makes this consistency model explicit, or offer no guarantees at all. But as a rule, I as a consumer should not care that you’ve chosen Raven DB instead of SQL Server for your back end. It’s just none of my business.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Everything.

This morning I started and finished, The UnStoppables: Tapping Your Entrepreneurial Power, by Bill Schley.

It’s a powerful book that brings us the essence and lessons of entrepreneurship, including what we learn from a band of Navy SEALs, Israeli investors, a branding expert, and a chairman of a multibillion-dollar tech company.

But my favorite nugget is about what we learn from customers.

Customers teach us how to be better.  

They are our ultimate business mentor, if we listen and learn.

Schley writes:

“Customers might as well be air and water; your business has no life without them.  Success is something you must learn from them because only they can teach it to you, through what they need, where their pain and pleasure are, how they want to be sold to, what kind of relationships they want to have with a company in your category, and so forth.  Customers hold the answers to all your most important questions about your product, service, and brand.  The Wonderful Paradox is that the secret of getting what you want is to think most about what they want.”

I’ve always been a fan of customer-connected development to build better software and ship better products.   Empathy for customers seems to be the difference that makes the difference when it comes to envisioning and creating great products and services.  (It works for education, too, when you put the learner-first, great things happen.)