Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

September 1, 2012

Book Review – “Universal Methods of Design”

Filed under: Design,Research Methods — Patrick Durusau @ 1:10 pm

Book Review – “Universal Methods of Design” by Cyd Harrell.

From the review:

I’ve never been one to use a lot of inspirational tools, like decks of design method cards. Day to day, I figure I have a very solid understanding of core practices and can make others up if I need to. But I’ve also been the leader of a fast-paced team that has been asked to solve all kinds of difficult problems through research and design, so sticking to my personal top five techniques was never an option. After all, only the most basic real-world research goals can be attained without combining and evolving methods.

So I was quite intrigued when I received a copy of Bella Martin and Bruce Hanington’s Universal Methods of Design, which presents summaries of 100 different research and analysis methods as two-page spreads in a nice, large-format hardback. Could this be the ideal reference for a busy research team with a lot of chewy problems to solve?

In short: yes. It functions as a great reference when we hear of a method none of us is familiar with, but more importantly it’s an excellent “unsticker” when we run into a challenge in the design or analysis of a study. I have a few quibbles with organization that I’ll get to in a minute, but in general this is a book that every research team should have on hand.

See the review for Cyd’s quibble.

For a copy near you, see: “Universal Methods of Design.”

August 28, 2012

Moon Shots, Flying Ponies and Requirements

Filed under: Design,Requirements — Patrick Durusau @ 4:40 pm

At Bruce Eckert’s Mind View site I read:

If somebody comes up to you and says something like, “How do I make this pony fly to the moon?”, the question you need to ask is, “What problem are you trying to solve?” You’ll find out that they really need to collect gray rocks. Why they thought they had to fly to the moon, and use a pony to do it, only they know. People do get confused like this. — Max Kanat-Alexander

Everyone has their own “true” version of that story that can be swapped over beers at a conference.

Or at a “Users say the darnest things,” session.

Is that the key question? “What problem are you trying to solve?”

Or would it be better to ask: “What end result do you want?”

To keep it from being narrowly defined as a “problem,” it could be an opportunity, new product, service, etc.

And to avoid the solution being bound to include Lucene, Hadoop, MySQL, SQL Server, the Large Hadron Collider, etc.

Let’s find out what the goal is, then we can talk about solutions and what role technology will play.

Think of it this way, without an end result in mind, how will you know where to stop?

July 10, 2012

Thinking in Datomic: Your data is not square

Filed under: Datomic,Design,NoSQL — Patrick Durusau @ 10:19 am

Thinking in Datomic: Your data is not square by Pelle Braendgaard.

From the post:

Datomic is so different than regular databases that your average developer will probably choose to ignore it. But for the developer and startup who takes the time to understand it properly I think it can be a real unfair advantage as a choice for a data layer in your application.

In this article I will deal with the core fundamental definition of how data is stored in Datomic. This is very different from all other databases so before we even deal with querying and transactions I think it’s a good idea to look at it.

Yawn, “your data is not square.” 😉 Just teasing.

But we have all heard the criticism of relational tables. I think writers can assume that much, at least in technical forums.

The lasting value of the NoSQL movement (in addition to whichever software packages survive) will be its emphasis on analysis of your data. Your data may fit perfectly well into a square but you need to decide that after looking at your data, not before.

The same can be said about the various NoSQL offerings. Your data may or may not be suited for a particular NoSQL option. The data analysis “cat being out of the bag,” it should be applied to NoSQL options as well. True, almost any option will work, your question should be why is option X the best option for my data/use case?

June 20, 2012

Neo4j in the Trenches [webinar notes]

Filed under: Design,Graphs,Neo4j — Patrick Durusau @ 4:18 pm

Neo4j in the Trenches

From the description:

OpenCredo discusses Opigram: a social recommendation engine

In this webinar, Nicki Watt of OpenCredo presents the lessons learned (and being learned) on an active Neo4j project: Opigram. Opigram is a socially oriented recommendation engine which is already live, with some 150k users and growing. The webinar will cover Neo4j usage, challenges encountered, and solutions to these challenges.

I was scheduled to watch it live but it conflicted, unexpectedly, with nap time. 😉

Watching it now and it is very impressive!

Lots of details and code!

Some specific points that I found interesting:

  • Know what questions you are going to ask the graph
  • Important things => nodes (can you say subjects?)
  • batch deleting (experiment with # of nodes) (Is this still an issue?)
  • reservoir sampling algorithm (you need to look deeply at this)
  • multi-threading fixed in 1.7 or later (issue discovered by profiling but should profile in any case)

Highly recommended!

Curious about your thoughts on the deletion issue?

On one hand, you can do “soft deletes” as discussed in this presentation but at some point, that may have an adverse impact on graph size and complexity.

On the other hand, “actual” deletion seems to be disfavored.

But change (read deletion/update) is a fact of enterprise data. (data generally but it sounds more impressive to say “enterprise data.”)

June 16, 2012

Knowledge Design Patterns

Filed under: Design,Knowledge,Knowledge Organization,Ontology — Patrick Durusau @ 3:58 pm

Knowledge Design Patterns

John Sowa announced these slides as:

Last week, I presented a 3-hour tutorial on Knowledge Design Patterns at the Semantic Technology Conference in San Francisco. Following are the slides:

http://www.jfsowa.com/talks/kdptut.pdf

The talk was presented on June 4, but these are the June 10th version of the slides. They include a few revisions and extensions, which I added to clarify some of the issues and to answer some of the questions that were asked during the presentation.

And John posted an outline of the 130 slides:

Outline of This Tutorial

1. What are knowledge design patterns?
2. Foundations of ontology.
3. Syllogisms, categorical and hypothetical.
4. Patterns of logic.
5. Combining logic and ontology.
6. Patterns of patterns of patterns.
7. Simplifying the user interface.

Particularly if you have never seen a Sowa presentation, take a look at the slides.

June 11, 2012

Social Design – Systems of Engagement

Filed under: Design,Interface Research/Design — Patrick Durusau @ 4:28 pm

I almost missed this series except this caught my eye skimming posts:

“We were really intrigued when we heard Cognizant’s Malcolm Frank and industry guru Geoffrey Moore discuss the enterprise/consumer IT divide. They liken it to the Sunday night vs. Monday morning experience.

It goes something like this … on a typical Sunday night, we use our iPhones/iPads and interact with our friends via Facebook/Twitter etc. It is a delightful experience. Malcolm and Geoff call these environments “Systems of Engagement”. Then Monday morning arrives and we show up in the office and are subjected to applications like the Timesheet I described in the previous post. Adding to the misery is the landline phone, a gadget clearly from the previous millennium (and alien to most millennials who came of age with mobile phones).

We then asked ourselves this additional question – did any of us attend a training program, seminar or e-learning program to use the iPhone, iPad, Facebook, Twitter, etc? The answer, obviously is NO. Why then, we concluded, do users need training to use corporate IT applications!

(http://dealarchitect.typepad.com/deal_architect/2012/06/the-pursuit-of-employee-delight-part-2.html)

Let me make that question personal: Do your users require training to use your apps?

Or do any of these sound familiar?

1. Confusing navigation. There were just too many steps to reach the target screen. Developed by different groups, each application had its own multi-level menu structure. Lack of a common taxonomy further complicated usability.

2. Each screen had too many fields which frustrated users. Users had to go through several hours of training to use the key applications.

3. Some applications were slow, especially when accessed from locations far away from our data centers.

4. Each application had its own URL and required a separate login. Sometimes, one application had many URLs. Bookmarking could never keep up with this. Most importantly, new associates could never easily figure out which application was available at which URL.

5. All applications were generating huge volumes of email alerts to keep the workflow going. This resulted in tremendous e-mail overload.

(http://dealarchitect.typepad.com/deal_architect/2012/06/the-real-deal-sukumar-rajagopal-on-a-cios-pursuit-of-employee-delight.html)

Vinnie Mirchandani covers systems of engagement in five posts that I won’t attempt to summarize.

The Real Deal: Sukumar Rajagopal on a CIO’s Pursuit of Employee Delight

The Pursuit of Employee Delight – Part 2

The Pursuit of Employee Delight – Part 3

The Pursuit of Employee Delight – Part 4

The Pursuit of Employee Delight – Part 5

There is much to learn here.

March 9, 2012

Functional thinking: Functional design patterns, Part 1

Filed under: Design,Functional Programming,Merging,Topic Map Software — Patrick Durusau @ 8:45 pm

Functional thinking: Functional design patterns, Part 1 – How patterns manifest in the functional world

Summary

Contrary to popular belief, design patterns exist in functional programming — but they sometimes differ from their object-oriented counterparts in appearance and behavior. In this installment of Functional thinking, Neal Ford looks at ways in which patterns manifest in the functional paradigm, illustrating how the solutions differ.

From the article:

Some contingents in the functional world claim that the concept of the design pattern is flawed and isn’t needed in functional programming. A case can be made for that view under a narrow definition of pattern — but that’s an argument more about semantics than use. The concept of a design pattern — a named, cataloged solution to a common problem — is alive and well. However, patterns sometimes take different guises under different paradigms. Because the building blocks and approaches to problems are different in the functional world, some of the traditional Gang of Four patterns (see Resources) disappear, while others preserve the problem but solve it radically differently. This installment and the next investigate some traditional design patterns and rethink them in a functional way.

A functional approach to topic maps lends a certain elegance to the management of merging questions. 😉

Comments?

Modesty as a Technology Elite attribute

Filed under: Design,Marketing,Programming — Patrick Durusau @ 8:44 pm

Modesty as a Technology Elite attribute by Vinnie Mirchandani.

From the post:

The core of my new book is about 12 attributes of what I describe as the industry’s elites. 12 adjectives – 3Es, 3Ms, 3Ps and 3Ss – made the cut: Elegant, Exponential, Efficient, Mobile, Maverick, Malleable, Physical, Paranoid, Pragmatic, Speedy, Social, Sustainable. (The TOC and links to excerpts are here). Each attribute has its own chapter – the first half has 5 to 7 cameo examples of that attribute, the second half is a fuller case study. So the Elegant chapter focuses on Human Centered Design, Google’s Doodles, Jonathan Ive of Apple, John Lasseter of Pixar and others, and the case study is Virgin America and how it has redefined the flying experience with technology.

One attribute I had on my long list was “Modest”. I had a case study identified, but struggled to find 5 to 7 cameos for the first half of the chapter. Let’s face it, it’s an elusive attribute in our industry where vendors send you press releases for every obscure award they qualify for:)

Curious, when was the last time you advised a client your product or approach wasn’t the best solution for their problem?

Isn’t that part of being modest?

If you are a customer, when was the last time you asked a vendor or even consultant to suggest an alternative solution, one that did not involve their product or services? If you have ever asked that question, how would you evaluate the answer you got?

March 2, 2012

A Computer More Powerful Than Watson

Filed under: Design — Patrick Durusau @ 8:03 pm

Who is Dr. Fill?

😉

The Economist in A match for angry words, reports on the construction of a cross-word playing computer, Dr. Fill, that must meet this constraint:

Dr Ginsberg gave himself an additional constraint in building his solver: that it fit on a laptop. That requires his software to be cleverer than Watson, which had many terabytes of data to sift through, but also makes it portable for shows. Dr Ginsberg says this is possible because crossword puzzle clues have correct answers that can be tested against the grid.

The story is amusing and the jury is still the success of Dr. Fill.

The important lesson is that Dr. Fill was designed to take advantage of the constraints imposed by the problem. Dr. Fill makes no attempt to be a fully general solution and therein lies the cleverness of its design. It solves the problem posed, not all other possible problems or variants.

How many unasked problems does your latest solution solve?

December 20, 2011

How Twitter Stores 250 Million Tweets a Day Using MySQL

Filed under: Design,MySQL — Patrick Durusau @ 8:27 pm

How Twitter Stores 250 Million Tweets a Day Using MySQL

From the post:

Jeremy Cole, a DBA Team Lead/Database Architect at Twitter, gave a really good talk at the O’Reilly MySQL conference: Big and Small Data at @Twitter, where the topic was thinking of Twitter from the data perspective.

One of the interesting stories he told was of the transition from Twitter’s old way of storing tweets using temporal sharding, to a more distributed approach using a new tweet store called T-bird, which is built on top of Gizzard, which is built using MySQL.

OK, so your Christmas wish wasn’t for a topic map with quite that level of input everyday. 😉 You can still learn something about design of a robust architecture from this presentation.

September 14, 2011

Seven Deadly Sins of Solr

Filed under: Design,Enterprise Integration,Search Engines,Solr — Patrick Durusau @ 7:06 pm

7 Ways to Ensure Your Lucene/Solr Implementation Fails

From the post:

CMSWire spoke with Lucene/Solr expert Jay Hill of Lucid Imagination for a few tips on things to avoid when implementing Lucene/Solr to reduce the risk of your search project biting the dust. Hill calls them the “Seven Deadly Sins of Solr” – sloth, greed, pride, lust, envy, gluttony and wrath.

Read for Solr projects. Recast and read for other projects as well.

August 27, 2011

Big Ball of Mud

Filed under: Architecture,Design — Patrick Durusau @ 9:12 pm

Big Ball of Mud by Brian Foote and Joseph Yoder.

I ran across a reference to this paper by John Schmidt in his reply to a comment on his post Four Canonical Techniques That Really Work (Or Not).

The authors present seven patterns of software systems:

  • BIG BALL OF MUD
  • THROWAWAY CODE
  • PIECEMEAL GROWTH
  • KEEP IT WORKING
  • SHEARING LAYERS
  • SWEEPING IT UNDER THE RUG
  • RECONSTRUCTION

All the superlatives have been used before so I will simply say read it.

Think about topic maps, Semantic Web apps, information systems you have helped write or design. Do you recognize any of them after reading this paper? What would you do differently today?

« Newer Posts

Powered by WordPress