• Create an algorithm which divides any two numbers of different bases together.
  Does your algorithm work with negative numbers?
  How about negative bases?
• How would you find a cycle in a linked list?
  Can you do it iteratively?
• Multiply a number by 7 without using the multiplication operator.
  Can it be done without addition?

Constraints: All manipulations must be made to the original linked list, and minimize use of external data structures as much as possible.

Hmmm of the day: The ideal solution is fairly brief and elegant, so don’t try to over-think it unless you need to!

• Four of a kind (ex: 5,4,5,5,5)
• Full house (ex: 5,4,4,5,5)
• Three of a kind (ex: 5,4,5,5,1)
• Two pair (ex: 8,4,4,5,5)
• Pair (ex: 7,1,2,5,5)
• High card (ex: 1,2,3,4,5)

Constraints:

• Return the String value or enum code (to your specification) representing each case

Hmmm of the day: Are there any poker hands which could fall into more than one category?

• Each node in the list has a pointer to the next element in the list, or null if no element is present
• Each node in the list has a data pointer which points to any arbitrary node in the list

Constraints:

• You are allowed to modify the list, so long as it is returned to its original state

Example:

Hmmm of the day: Can this be solved using pointer arithmetic, and if so, is it the most efficient solution?

• What chair you are on
• The chair coming in the opposite direction visible to your left at the current time

At what point do you have an accurate estimate of your progress? When you are at that point, what is your percentage progress to the top?

Constraints: You are not given the number of chairs on the chairlift.

Constraints: All manipulations must be made to the original array, but a single staging variable can be used.

Hmmm of the day: Can this be done for N by M arrays as well? If so, how? If not, why not?

Constraints: Your checkForWin method should be relatively efficient (i.e. it can’t have O(n²) efficiency). Think you can do it in O(n)? How about O(1)?

Hmmm of the day: The most efficient way to put a piece may seem a little ‘backwards’ at first.

If you’re saying no, then you’re either a legend or you might have some delusions of grandeur – but in any case a little practice never hurt anybody. I’ve decided to keep my skills fresh, I’m going to try and create (and tackle) a new problem every day, and I’d like to share them with the rest of the world so that you might benefit as well.

This concept is by no means new, and I encourage you to check out Dave Thomas’ Coding Kata, which is the earliest example of Coding Kata I can find. I really like the concept, but unfortunately the site is no longer maintained, so I’d like to pick up the torch and carry on from where Dave left off.

Some of them you may have come across some of before, but I’ll try to keep them as fresh as possible. I’ll also post the answer in the comments the next day for those who are interested. Karma points to whoever gets it first before that though

This summer I wanted to make my own Multitouch interface as a side project, but I wanted to add a new twist to it – I wanted to make it work in thin air, without any physical contact. I saw some very interesting projects on touchable holography , and I’d also just finished watching District 9 (my favorite part was admittedly some of the cool UIs that the aliens had), and I couldn’t stop but think… how cool would it be to have something like that??

I started sketching a bunch of prototypes in my spare time, and I finally came up with one inspired by some of the fantastic work of Johnny Chung Lee. The prototype used a matrix of infrared LEDs, positioned on the top of a display, which would reflect infrared light back to a user (standing an arbitrary location away from the display). The user would be wearing gloves with reflective tape on each finger, which would in turn reflect the infrared light back at two infrared cameras (read: wiimotes), positioned at either side of the display.

When the user first starts the system, they must calibrate it before they use it. A quick sample is done of the area to see if there are any areas emitting infrared light and if so, to remove them from the sampling area so they aren’t treated as input from you. The system plays a tone and the user then creates a brightness threshold by presenting all ten fingers at a point which functions as a virtual wall – it’s very similar to a mime’s wall performance.

Anything that is registered as brighter than the average of all ten points counts as a push, and for these reasons we can also detect virtual pressure based on how bright the light is being reflected when compared to the initial threshold. But we’re not done yet! We still need to know where the screen is, so after creating the virtual wall the system prompts the user to point at four crosshairs, positioned at the four respective corners of the screen.

CV algorithms are then used to detect if there is a ‘press’ and if so, how many and where. Using pre-existing libraries for processing mutlitouch input, we are able to process the information read from the cameras and use this information to recognize various gestures, such as pinching and a finger coming in and out of the threshold.

The current version now has ‘darth vader gloves’ which have IR LEDs wired right into the glove. This not only helps cut down on power consumption, but it also gives more relevant readings in the cameras as lots of noise would be generated by the IR light rays hitting various parts of the reflective tape. The current prototype doesn’t support any more than 4 points acting in a multitouch gesture either at this point, but I plan to expand on this soon, school permitting

Youtube videos, photos, howtos, specs and the like will hopefully find their way up here soon, coursework permitting

The procedure was more or less the same for every project. I would create my user interface in Photoshop and slice it up (or if I’m feeling exceptionally keen, straight to the code), and then piece by piece I would snap little bits of interface together to form an overall gestalt. After many refinements and tweakings, I’d prepare a demo and portfolio for my client and showcase the new interface. If all went well, I’d begin design of my Controller and Model components from then on, giddy with satisfaction that the client liked the demo.

But that’s when the honeymoon period starts to end. Quickly.

The app now has all these lofty requirements and proposed features, and there’s a substantial chasm between the various elements. Solutions pop into your head on how to connect them, some more eloquent than others, but invariably the initial solution isn’t as clean-cut as you’d like it to be. Several pads of paper and pots of coffee later, a nice design emerges for your Controller and you swiftly bind all the GUI elements to their proposed functions. Life is good. But then there’s the Model…

After slewing through the Model, and getting that last unit test to pass, you finally have first release candidate to show to the client. You’re pleased with yourself, glad that you pulled it off and you’re happy with the results, and the client is too. The client then pulls you aside afterwards and was wondering what happened in the past few weeks. Despite the fact that you told them it was going to take a while to ‘do the plumbing’ to connect everything, they expected something working earlier than this, after all – they saw an interface with everything they wanted to see on it! How hard could it possibly be?

Time after time I find that this approach suffers from the Iceberg Effect, in addition to the dangerous waters you have to navigate through to avoid a Frankenstein app and other anti-patterns. I assumed it was the best way to go about doing things (for me) despite it’s shortcomings, and I continued on my merry little way… until this weekend.

What if you didn’t start with the View, or even the Model – and just went straight to the Controller. This way you could start on an app which knew from the ground up the best ways to interact with the Model and also the best ways to interact with the View.

The most essential moment in the development of an application I believe is when you realize how the users intent can be fulfilled, and since this is predominately Controller logic anyway, you’ve basically got the app in the bag. Here are a few pros to this approach:

• You can construct a modular Controller around the users actions and not the nitpicky needs of the app infrastructure
• You still have an understanding of what functionality the user will be able to use in the View
• You don’t need to make any compromises with the design of your model
• You won’t be a victim to the Iceberg Effect
• Can construct unit tests right away for Test Driven Development
• Less likely to paint yourself into a corner since you know the app’s logic and constraints up-front
• You and the client have reasonably high visibility on the project

No methodology would be complete without it’s drawbacks though. Here’s a few which I think can come into play:

• Longer delay in getting the interface ready means that there could be a small back-and-forth between Controller and View handshaking if the client makes repeated changes
• More time needed up-front to flush out the design

So what do you think? Is this a steaming pile of balderdash, or do you think it’s a happy compromise in this day and age of app development? I will be trying it on my next project, and I’ll keep you posted with the results.