Can you develop code to effectively solve a problem without understanding the problem first? (writing code to solve Sudoku puzzles)

You shouldn’t have to think too hard to answer this question. In order of most likely answer first, least likely last (I hope), your answer could be one of:

a) No. How can you solve a problem if you don’t understand what it is that you’re trying to solve?

b) Possibly, if your approach to solving a vague or poorly defined problem is to ask clarifying/fact finding questions to investigate and gain an understanding of the problem so you can get to a position where you’re able to solve the problem.

c) Yes. (Really?)

There’s no correct answer to this question although I hope you initially answered (a), but (b) is a valid possibility if you consider the effort to understand a problem is an essential part of solving a problem (which of course it is).

I decided I would have a go at writing a Java app to solve Sudoku puzzles. I’m familiar with the rules of Sudoku and have solved a few puzzles by hand. I’m not an expert by any means, but I know enough about this type of puzzle to realize there’s probably at least a few well understood algorithms for effectively solving them, but as I started out I wasn’t familiar with any particular approach.

So here’s my experiment: I decided I would deliberately avoid doing any background reading on known algorithms or reading any articles or discussions on approaches for how to solve, and would attempt to blindly develop my own approach to solve a puzzle to see how successful (or otherwise) I would be. I know the rules to the puzzle, I understand what the end result must be, so how hard can it be, right?

For those unfamiliar with Sudoku, here’s the 3 rules:

  • each 3×3 square must contain each digit 1 through 9 with no repeated values
  • each column must also contain each digit 1 through 9 with no repeated values
  • and the same rule for each row, 1 through 9, with no repeated values

Here’s my starting puzzle that I used to write my code against:

      | 8 1   | 6 7   
    7 | 4 9   | 2   8 
  6   |   5   | 1   4 
- - - + - - - + - - -
1     |     3 | 9     
4     |   8   |     7 
    6 | 9     |     3 
- - - + - - - + - - -
9   2 |   3   |   6   
6   1 |   7 4 | 3     
  3 4 |   6 9 |       

(Puzzle generated by WebSoduku)

My initial approach for my algorithm was to follow the steps I would go through by hand if I were solve a puzzle on paper. This already set me off at a disadvantage because I don’t think I’m particularly skilled or experienced at solving Sudoku, so I wasted some hours trying to capture these steps in code. Going down this path I realized if you take this approach, you mentally ask several questions as you look for possible values for empty squares, but it’s not not the answer to any one of questions that gets you a correct answer, it’s the combination of answers to multiple questions (because there’s 3 constraints, above, that you need to follow). So following this approach, I wrote code to iterate through the complete grid applying my limited set of questions to find potential values for each empty cell. The result was after a couple of iterations I had inserted values into all empty cells as sets of potential values, but my approach was not complete enough to be able to solve the example puzzle I was using for testing.

This is where I reached my point of realization. Clearly I did not understand enough about the problem to be able to write a program to solve it.

After some debugging and tweaking to my approach, I did reach a point where I could solve my test puzzle in 7 passes through the grid, but when testing the same approach with another easy puzzle, my approach failed to reach a solution. So my approach only partially works when I have a starting point with enough values, or a certain distribution through the grid, but fails to solve all puzzles.

At this point I could have continued blindly in the same direction, but I decided I had already proved to myself my point that you can’t solve a problem if you don’t understand what it is that you’re trying to solve. It was time to read up on the the established algorithms to solving, so I could understand what it was that I was missing.

There are a number of established algorithms for solving Sudoku, and I won’t describe or cover them all there, but there’s a good summary on this wikipedia page. The approaches range from brute force (sequentially testing each value 1 through 9 in each cell, with backtracking to prior cells if chosen values fail to find a solution, to variations such as Donald Knuth’s Dancing Links algorithm.

My conclusion to my original question though is clear: had I recognized the problem as an example of an exact cover problem, I would have known that there are established algorithms for solving this type of problem.

You can’t solve a problem if you don’t understand what it is that you’re trying to solve.

If you’re interested in taking a look at my partial solution you can find it here on my Github.

JavaOne 2016: Oracle’s ‘refocusing’ of the EE8 proposal

Oracle’s planned Java EE ‘announcement‘ at JavaOne 2016 turned out to be (based on the announcement from the Sunday keynote and the Java EE 8 roadmap session by Linda Demichiel, EE spec lead for EE JSRs) a ‘refocusing’, a realignment to bring Java EE more in line with current trends, particularly to support deploying EE applications to the cloud and the development of microservices.

So what exactly is going to change? For the new EE8 spec proposal, with finalization now planned for 2017,  some previously proposed features for inclusion are now going to be dropped, namely:

  • MVC 1.0
  • JMS 2.1
  • EE Management apis 2.0

Given than MVC 1.0 was a new EE web framework as an alternative to JSF (not adding new technology but built on top of what we already have with a Reference Implementation already built out), this is perhaps the most surprising removal. Given the new focus of cloud and microservices however, this makes sense, as it doesn’t really add anything towards supporting the new goals.

Everything else in the original EE8 JSR 366 is going to remain in the new EE8 proposal.

New features to be added include a new feature for supporting Health Checks, and a new Configuration proposal to standardize external configuration of deployments – both of which will be useful to support deployments to the cloud.

Is this ‘refocusing’ enough? Is it going to be finalized soon enough? For an EE8 target of 2017, and EE9 of 2018, is it too little, too late?

Given that you can use current EE features today with frameworks like Spring Boot and Dropwizard to build and deploy microservices, is a standardized cloud/microservice focused EE platform still relevant?

Alternative runtimes like WildFly Swarm and IBM’s Liberty Profile are giving runtime flexibility and allow you to pick just the features your app needs at runtime (and are available today). Rather than an all-in-one EE runtime container, is a ‘pick n mix’ type approach more relevant to support the current popularity of microservices?

Notes from Raspberry Pi with Java 9 session – CON6210 – JavaOne 2016

A few interesting notes from the Java 9 Embedded on Raspberry Pi, session CON6210, presented by Stephen Chin.

Currently streaming live on YouTube: https://www.youtube.com/watch?v=v95y5CzvcZ4&feature=youtu.be

Full live stream schedule is here: https://community.oracle.com/docs/DOC-1005786

  • SE9 Embedded will be available in a ARM build for the Raspberry Pi
  • This ARM specific build will only be available for Pi 2 and 3 (not the original Pi 1 A/B and + models, as it’s been compiled for ARM Thumb-2 instructions, and these are only supported on Pi 2 ARM CPU and above
  • AWT, Swing and JavaFX will all be supported on SE9 Embedded on the Pi
  • Interesting side note about modular Jigsaw in SE9 – apparently the module file packaging and compression is moving away from zip based Jars, to another format that’s more efficient for class lookup/retrieval