Poker, and other things...

If my 2018 blogging self had known that I'd take an unplanned 6 year hiatus from this blog, I'd have time-traveled to warn myself about a bleak future. 

So what's happened since then?

I am still around, and in my tenth year as an independent engineering consultant. Many of those years since kept me pretty busy. When you add that I lost at least half a dozen family members, including my father, all the train wreck that was Covid, trying to raise two teenage boys, being pretty involved with my local fishkeeping club, and also the project that I'm about to talk about, somehow blogging was one of those things I wanted to work on, but just ended up not making the cut in my priorities. 

During during the early days of the Covid pandemic, I had a lull in consulting work, and I also started playing a fair amount of computer poker in my off time. I played online, and also bought some old used xbox poker games off ebay. I'm not a gambler, and mostly don't play poker for money, except with local friends occasionally. I have just been a fan of the game for a long time, as a card game. 

I got the idea to start a "Pandemic project" with my down time. All of the poker software I've ever played has always left me feeling like it could be so much better, and when my ego flairs up I think "I could write something better". A lot of the poker games were pretty limited, and a majority of them only support a single type of poker - the most popular form if it, Texas Hold 'em. Texas Hold 'em is a fantastic poker game, but there are so many other ones out there that are a lot of fun too. Even minor tweaks to game rules can have a pretty big impact on the game dynamics. So I decided I would build a better poker game. I also decided after a lot of internal debate that I wanted to make a go of making it something that could have potential as a revenue stream. Being my own boss is part of why I do consulting (by no stretch the main reason), and building and selling your own product is the epitome of being your own boss. Additionally, while I have worked on many neat and exciting projects for client over the years, nothing is quite as fun as working on exactly what you want to do. 

So around April of 2020 I started working on a poker engine. At first it was only an "engine", as in it focused on the "Business logic" and rules of playing poker, without really making a game itself.  Work picked back up pretty quickly, so I focused on working on my poker code on nights and weekends when I wasn't spending family time or taking care of my fish. Working on a product as a side job in free time does give you a lot of freedom to not worry so much about deadlines or development costs, but in part it was therapeutic for me to dream up a feature and three days later have it functional. That's not to say it was done informally, I still used a lot of "professional" software development processes. I have a bug-tracker, unit tests, continuous integration, and for the larger features, I even wrote design documents. 

 4 years of feature creep later, I have something I'm very proud of, a full-blown single and multiplayer poker desktop application. I have put it up on a website, and I'm currently running a closed beta in that it's limited mostly to people I know personally. It's roughly around 300,000 lines of code, I could see it getting to 400,000 lines before I run out of polish and features to add. It's by far the largest personal project I've undertaken, so there is a lot of "me" in it. Almost all of it, including the server-side stuff and website, are written in C#. I think in just about any other tech stack, I would not have gotten to this point yet. 

My hopes are to resurrect this blog to semi-regular posting, or at the very least, blog a few times a year, and to make some posts that go into more detail about the architecture and process and little interesting tidbits about this project that's had a significant part of my focus for the past 4 years. 

At the time of this writing, I'm still in closed beta, but future readers ought to go check it out if they are interested in poker. You can also go to my site to sign up for future beta testing. 

https://straightuppokergame.com

--P

A Blast from the past with Sedition.

A few years ago, I published an Android game, mostly as a hobby. I actually fell into making the game, it was originally planned to be a demo for a talk I was considering giving at a conference. The plans few through, but I kept on tinkering with the game. It was also a good source of material for earlier posts on this blog.

The result was Sedition for Android.

About a about ago, I got the crazy idea to port the game to run inside a browser. I have done some work with the Google Web Toolkit in the past, and I've been very impressed with the way in which it can make developing a rich client side application feel like you're developing a traditional desktop application. GWT compiles Java language code into very efficient complied Javascript. With the advent of HTML 5's media support and WebGl, I had everything I needed to take the Android source and port it.

Originally, I called it "Sedition 4 Chrome", since I was planning to make it a Chrome packaged app and put it in the Chrome app market. I may still do that. Writing a Chrome app gives you access to more features that you can do with lowest common denominator general web apps.

It has numerous quirks, and the rendering especially is not quite right in several ways, but that actually matches the last released version of the Android version. I do plan to fix both eventually. Some of the rendering oddities, especially "sprite parallax" are much more noticeable on large screens than the small mobile screens the game used to run on.

I also have a few ideas for the general engine I developed while working on that game that might come in handy for some of my other projects.

It's a fun project to work on, and in part I wanted it to server a sort of a portfolio of what types of applications I can develop.

Play it yourself at

http://anibit.com/sedition/


--P

Learning Programming

To say that I'm a software development enthusiast is an understatement. I think about it literally all the time. I think about application architecture as I'm falling asleep in bed, I think about algorithms in the shower, I daydream about debugging techniques while driving down the road(ok, only at stoplights ;) ). I think about other programming tasks as I'm programming. That last one isn't always a good thing, and I try to keep it in check.

When you have the level of passion for something that I have, it can become easy to be biased, and blinded to some of the realities of it. I've spent most of my life with the perspective "programming is such a pleasure, everyone should do it". I still have vivid memories of the first time I saw source code at 11 years old, and the instantaneous explosive ignition of a flame within me to become all about it. I can still recite the 6 line program almost verbatim:

10 LET N = RND() * 10 +1

20 INPUT "enter a number from 1 to 10", G

30 IF G = N THEN GOTO 50

40 PRINT "WRONG!, GUESS AGAIN"

50 GOTO 20

60 PRINT "CORRECT!"

Or something like that, I didn't write it, I'm not sure who did, maybe it was my best friend, who showed it to me, maybe it was from a book, but I had a googly-eyes over it "I can make a machine make decisions!". 

In the course of my life, I've sought to spread this joy to those close to me - my siblings when I was younger, my wife, my kids. I've been in a wishful denial about is that some people just aren't wired for the programming mindset. This is not a bad thing, the diversity of the human mind is what makes our species great. My wife has an engineering background, and has worked in the IT field, and had worked as a software developer, and took courses on expanding her software development knowledge. But by her own admission, "I'm just not that into it". She switched careers and now works in special needs education. She found her own passion. 

Similarly, I've exposed my kids to various incarnations of educational outreach designed to ignite a similar spark within them. They've had orders of magnitude more opportunity to become involved with crafting algorithms that I did. They're all still younger than I was when I saw my first code. My kids (and wife) are incredibly smart, but the jury is still out on if they have the same little something that makes me crave coding. 

There's been a push in recent years to get greater exposure to a wider range of youth to encourage an interest in software development, as part of the "STEM" movement. While this is a fantastic thing, I am starting to think that we should also recognize that software development, or evening engineering in general (Contrary to some, I believe that Software Engineering is a *real* field of engineering, that simply has not matured enough yet as a career field to have all of the kinks worked out) is not for everyone. For one thing, it is hard to do correctly. The goal of programming education should be to facilitate, make it a viable career path for those who have the desire, and to kindle a desire in those who may not have had the opportunity(though in these days that is a diminishing demographic). What we should not do, is to "sugar coat" the art and science of it, pretend that the sole barrier to a career in software engineering is a lack of an friendly introduction and adequate access to computer time. It takes a lot more than that. 

This port was inspired by an article I ran across this week:

http://mikehadlow.blogspot.com/2015/12/learn-to-code-its-harder-than-you-think.html

The gist is nicely summed up as:

"All the evidence shows that programming requires a high level of aptitude that only a small percentage of the population possess. The current fad for short learn-to-code courses is selling people a lie and will do nothing to help the skills shortage for professional programmers"

I more or less agree with this assessment, but in addition to the aptitude, it requires the passion for it, and "mental the circuitry". The basic knowledge of writing  or understanding a few lines of simple code is a low bar compared to becoming a master of the craft. I think the percentage of the general population that possess the aptitude needed to develop code is greater than the article implies, perhaps it is even a majority of the population. However when considered with the subset of the population that also has the motivation, passion, to develop into a master, I arrive at the same conclusion. "Aptitude" is a loaded term, and unfortunately, carries a connotation of exceptionalism. That is not the intent, it is a fact that with any particular skill, only a certain percentage of the population posses an aptitude for that skill, it does not make them elite, only wire for that skill. I have precisely 0 aptitude for playing musical instruments, that means almost nothing outside the context of discussions on musical ability. 

The takeaway is an idea that I have has bouncing around in my head for a while. There is no shortage of "learn to code" and "everyone can be a programmer" education out there, but there is a dearth of resources for those who wish to "take things to the next level".. Once someone gets through the basics, where do they go from there? For the most part, they are on their own. There needs to be more "experts" coming forward to develop the intermediate and advanced levels of educational programs for aspiring Software Engineers.

--P

The D programming language, "dlang" ,part 2: Templates

In my last post, I gave a brief overview of my background and interest in exploring the D programming language from a background of a seasoned C# developer. (Also note that I feel all "curly bracket" family of languages developers would appreciate D, it's just that if C# is one of your personal favorite of the family, D may have even more for you to like.)..

Now for the good.

After enumerating so many points lacking in D, you may wonder why I'm so enamoured with it. The language itself has many features found in C#, and also many features C# lacks. In some case's D implementation of a feature is superior to D. Let's give a brief introduction to some of the really cool parts of D that have no counterpart, or aren't done as well, in C#. 

Templates

C# has generics, but as I hope to explain in future posts, they're not nearly as powerful as what D can do. Anyone who does worked a lot with C++ templates and found C# generics lacking, would be pleasantly surprised with D. D brings back the power of C++ templates without all the awkward syntax and linking issues you have with C++. Templates are a concept in D somewhat orthogonal to the definition of a type or method. A template is just a parameterized piece of code. You can place class and method definition inside a template, then those classes and methods are templated. 

public template ListTemplate(T)

{

public class List

{

void add(in T item)

{

     //stuff

}

  //etc

}

}

That illustrates the idea, but if all you really want is a old fashioned template class, D, being pragmatic, has a shortcut:

public class List(T)

{

void add(in T item)

{

}

}

In addition to classes and functions, you can declare variables and type aliases inside templates too.

You can have value template arguments as well, something that doesn't exist in C#.

public class SillyArray(int size)

{

int[size] _myArray;

}

Now, the size parameter is part of the type of declared variables. If you've never worked with template value parameters before, it might not seem obvious what you gain from them. Because it affects the type of the class, just like a type parameter would, you could do things like define a range type:

public class Range(int low, int high)
{
int _value;
this(int value)
{
assert(value >= low && value <= high);
_value = value;
}
}

Now you have a type where the legal range forms part of the type itself, and the compiler can distinguish the legality at compile time.

Let's define an alias, akin to C++'s typedef though more powerful, to reference the type:

alias liquidWater = Range!(32, 212);

Now later on we could define a variable,

auto myCup = new liquidWater(4); //error, out of range.

In this case, the compiler can determine that the assertion will fail, and so it flags it as a compiler error. This is another great point about the D compiler is that it will evaluate assertions at compile time when it has enough information! When it doesn't it will still evaluate it at run time.

Type constraints.

C# does have a limited type constraint system for generic type parameters:

class foo<T> where T : IDisposable where T : new()
{

}

This lets you declare that what type is used to instantiate foo must implement IDisposable, and that it must have a parameterless constructor(this feature seems like an odd special case to place in the language, I always wondered why they stopped there).

In D, it gets waaaaaay cooler than that. Essentially any logic you can supply that can be determined entirely at compile time can be used as a type of value constraint.

Going back to our range type, lets say someone did something like this:

alias invertedRange = Range!(100, 0);

Notice how the "low" parameter was greater than the "high" parameter? As the designer of the Range class, you never intended that. How might you prevent someone from doing that in a way that it's caught at compile time?

You add an template constraint expression:

public class Range(int low, int high) if (low <= high)
{
int _value;
this(int value)
{
assert(value >= low && value <= high);
_value = value;
}
}

Now the compiler will not allow the inverted range alias declaration. As long as the logic can all be determined at compile time, anything is possible as a constraint, even function calls!:

bool isLower(int a, int b)

{

return a < b;

}

public class Range(int low, int high) if (isLower(low,high))

{

int _value;

this(int value)

{

assert(value >= low && value <= high);

_value = value;

}

}

This syntax really gives you a rich language for expressing contracts between parts of code in ways that I have not seen in other languages. These are compile time contracts, validation is immediate, not through unit testing or function tests, but before you ever have executable code. Your intention as an API designer can be very explicit. That, is what make me smitten with the language.

I''ve barely scratched the surface of what you can do with D's generic programming system. If you want to know more, check out the very well written online book "Programming in D" by Ali Çehreli at http://ddili.org/ders/d.en/templates.html

Until next time,

--P

The D programming language, "dlang" - Part 1

I've started a new project recently, related to a product I want to develop. It's a software-only product, but it's electronics related. I thought it would be fun to chronicle the development and design progress.

I'm working on a tool that I don't think really exists yet, at least in the way I envision it. As usual, I'm going to be coy about specifics until I'm ready to announce it.

I've mentioned in the past that I'm a programming language geek. I still feel that C# is one of the overall best, most productive programming languages out there, and it continues to get better with each new edition of the language. Now that Microsoft has let Linux and OSX join the .Net family (even if they are still somewhat still the red headed step kids, which I feel will change in the not too distant future), I'm hopeful that developing desktop code on .Net will become a reality.

I have had it on my list forever to give the "D" programming language a go, and this project presented itself as a good opportunity to try it out. D is a non-main stream programing language that has been around since 2001. Despite it's fantastic design and feature set, it's adoption has been slow and steady.

To make a long story short, I had it as a goal to use D to develop my new software. I admit that a small part was driven by the desire for something new and shiney, but I have spent a decent amount of time researching that language. I think that D has some of the right set of features for large and medium sized application architectures. D has a bag of features at your disposal that very few languages have and have done right so that you can pragmatically "get stuff done".  Scala is another contender in this area, though in my experience Scala veers a little too much into academic theory and a little shy on the pragmatism end of things (for example loop flow control keywords were omitted because the language designers felt they encouraged imperative programming style.). At the same time, Scala, being a language that targets the Java virtual machine, is encumbered with some of that platform's limitations.

In the end, I decided to stick with C#, but not without a heavy heart and solemn face. I still have D in my heart, and will take another shot at it in the near future, it just wasn't the right fit in this case. The primary reasons for ultimately goign back to C# were the Framework support, especially GUI support.

Note that I'm be no means a D language expert. I've never authored any sizeable application in it. I'm still learning it. I'm bound to make a mistake or two here, please call me out if you spot something!

Comparison to C#

What's up with me these days.

I have so many moments where  I think, "that would be a great blog post". The end result is what you see on Bytecruft, not so many posts. I really enjoy writing a blog, though somehow it always ends up close to last in priorities.

My business, Anibit Technology is doing OK. Not great, but not exactly where I had hoped. The hardware business is hard, really, really hard. Re-selling other's hardware is even harder. I love being part of the "Maker" movement, however marginal. I wanted to make it something that I could do full time by diving head-first into it, and supporting myself and family by doing something that I love. That's the ultimate American dream, right?

My plan was, and more of less is, still something like this:

1. Design and produce hardware with accompanying software that will help people who like to invent, or who want to lean to invent.
2. ???
3. Profit.

Alright, that's a little facetious, but not as far from the gist of it that my characterization doesn't make me a little self-conscious.

A ramble on web development from a non-millennial developer's perspective.

Having a background in desktop and embedded software development, web application development technologies frequently stymie me. I get "the good parts" of Javascript, but I often feel like Javascript makes what I've come to consider good practice in application architecture difficult. The loose typing of Javascript is an appeal to so many, but it can make it hard to maintain a very large code base.

Consider:

Javascript:

var foo = function (payload) {

    var timestamp = payload.getTimestamp();

    //some code that does something with timestamp, etc...

}

There is an inherent code interface requirement for anything passed into the function foo that it must have a member function named getTimestamp, and that function must return a type suitable for the expected operations. 

There are essentially 4 ways in Javascript that a developer who wished to use function foo can discover this implicit requirement:

• Inspect the internals of the function foo, to learn all of it's expectations of the passed in type
• Read documentation bequeathed by the author(s) of foo
• run a "lint" -type tool for static analysis to catch improper usage. 
• run the code and debug the exception that gets thrown when you pass it an invalid object.

All of these options, except maybe the lint option require manual human action. All of the options, including the lint option, are quite fallible. I did not include a 5th option that is unit testing, unit testing is a good thing, but it does not even begin to help this particular problem. For starters, the unit test will not replicate the real world usage. Where was the payload object created? It might come from a call back from within a callback from within a callback using an object stored form some earlier callback. Similarly, lint tools are a good thing, but they are far from perfect as well, and more cumbersome to use than a compiler.

compare the Javascript with the equivalent C#

interface IPayload

{

    DateTime getTimestamp();

}

void Foo(IPayload payload)

{

    var timestamp = payload.getTimestamp();

    //do some stuff with timestamp

}

Now this example is trite, but the point is that as the size of your application grows, and you pull in more and more 3rd party code, the occurrence of problems surrounding the "hidden contracts" in dynamic languages like Javascript grow. In the C# version (or just about any statically typed, compiled language), you know immediately, and so does the compiler, what is expected of the payload object passed to Foo, it's contract is clear, and rigid. 

There is a lot of thing appealing about how Javascript works and dynamic languages. Due to the nature of web the web, deployment has always been more of a challenge than with desktop applications. The ability to swap out a single file has it's appeal. Java server side tried to alleviate this with the servlet system and WAR files. It's also more terse, and superficially more forgiving. (Any object could be a "payload" in the Javascript version so long as it has access to the getTimestamp prototype. 

Also, there is this appeal in the perception that a change in a third party dependency won't break your application. I think the problem is with dynamic scripting languages is that your relationship to your dependencies becomes a "gentleman's agreement", and not an enforceable contract. Say in the next version of the foo library,  the authors made to following changes to foo:

var foo = function (payload) {

    var timestamp = payload.getTimestamp();

    payload.resetTimeStamp();

    //some code that does something with timestamp, etc...

}

Maybe this was documented, no big deal right? If your code was such that you could find everywhere that payloads were created, great. But what if it's not that easy? Again, this is trite, but illustrative of a general problem, use your imagination. To fix this problem could involve a lot of debugging, text searching, inspecting logs, etc. Then when you have to integrate your code into another department's application, you have to do it again.

In C# the compiler would immediately find all cases where the 3rd party library broke you. 

Ok that was a rather winded way of saying "dynamic languages pose extra challenges for large applications". This is also true of Python. This isn't to say I don't like Javascript or Python, that can do many things that would be hard or even impossible in other languages. The asynchronous nature of Javascript lets you do a lot without multithreading and the evil, evil shared memory synchronization patterns you must use with it. At the same time, I miss the comfort of knowing my object is an apple, not not having to debug to figure out I was suddenly passed an orange. 

One of the great things about Javascript is the ecosystem, and the shear massive amount of effort and work going into it. There are more Javascript libraries and frameworks and tools than one could ever learn in a lifetime. Javascript is ubiquitous,

The second aspect to Web Development that makes me marvel at it's popularity is way in which user interfaces are created, the DOM. Creating user interfaces in html is for the self-taught an execise in cooking "div soup". Go to any major modern website; Facebook, Twitter, CNN, and open the page in the dev tools in your browser off choice. Invariably, it's built with nested div upon div upon div's. The css is typically where the magic happens that makes those div actually look and behave like the site you're visiting. But it's a dark art to getting it right and authoring, that comes with experience, not necessarily the good kind. It takes years of learning the arcane quirks like "oh you need to wrap that in a div with float:left" or "oh Firefox need's explicit widths on those elements". Compared to most of the Desktop UI frameworks I've worked with, traditional web UI development feels .... irrational.

There is hope though, I think things are getting better. HTML 5 has enabled the tools needed to make vast improvements. A lot of HTML 5 is not implemented yet, and even more is still experimental or bleeding edge. Web Components offers a path to maybe one day doing away with the div soup and making a more satisfying meal. I have been experimenting with Google Polymer lately, and it's still very new, but has me excited that I might soon be able to build a browser app with markup that makes sense for a UI.

Though I never used Silverlight much, I've used it's big sibling, WPF, extensively. It had its warts for sure, but creating a UI was so much more intuitive than the div soups/css hacks of HTML we see today. It makes me sad that Silverlight, met an untimely end. I feel it's demise was more due to a shift to mobile devices and away from browser plugins, than its technical merits. There is a project that I ran across in my feeds recently, Fayde, which is a re-imagination of Silverlight in pure Javascript. I was able to get a basic UI rendering in minutes, despite never using it before. It is super-neat-o.

For those crufty programmers such as  myself, with a slight allergy to new-fangled dynamic languages, there are a lot off tools to let you build Javascript applications in the language of your choice. Tools like Google Web Toolkit(Java), Emscripten(C/C++), Typescript, Dart, JSIL(C#/VB) all let you shield yourself a little bit from the idiosyncrasies of Javascript and the very loosely-typed nature of it.  It used to be that "strongly typed" was generally considered a virtue in a programming language, it seems like the rise of browser based development has flipped the consensus. I predict it will come full circle once really large "SPA" web or nodejs application developers start feeling the pain of maintaining multi-million line, aged, legacy applications that were built on gentleman's agreements.


--P

 [Note, I struggled to find the right title for this post, no offense to millennial engineers is meant by it. I think if you learned how to program before Google was a thing, you cut your teeth under a different set of common wisdoms than today. Some are now obsolete but others got lost to the noise of the new shiny. The merit of strong explicit contracts seems like one of those lost wisdoms these days. I'm always keeping up with the new shiny, while trying not to loose touch with my roots. Millenials are crazy-smart and talented. Now get off my lawn!]

Stupid Simple Website Metrics

I wrote a tool that I am open-sourcing to keep track of website server performance. It is very un-fancy. It tries to do one job and do it well: Log and display page load times. (Wait, is that two jobs?)

Background

Over the past several months, I've spent way more time than I had anticipated stressing over, testing, and trying to fix the abdominal performance I had on anibit.com. I was using a low end hosting service intended for personal websites, which I had expected to on the slower side of things, but it got so bad that page loads could take up to 45 seconds. That was even at times when I was the only user other than the failed spam-bot log ins once a minute or so. I would have been satisfied with 6 second loads even though that is considered a generally poor user experience. Something had to give. Anibit was on a shared server with probably dozens (my host service doesn't reveal that I'm aware of how many websites share your host). Any of them could misbehave and bring the server to it's knees until the hosting service brought the hammer down on them, which it frequently needed to do.

JSIL

Just a short post:.

I think JSIL:

Is the bees knees.

It's a .Net bytecode (CIL, "common intermediate language") to JavaScript compiler.

Despite the fact that I don't blog about it often, .Net, its frameworks, libraries, tool, and the C# programming language are safely #1 at the top of tech things I love. My .Net Micro Framework project (still in progress, but on temporary hiatus), is my attempt to blend C# with my enthusiasm for embedded development.

Keep an eye on JSIL, I think it will go places. It's the way Silverlight should have been done.

--P

Android ADT r17 released today.

[Updated, it's the ADTr17 that's was released]

Google released the final/stable version 17 of the ADT today. There are a number of fixes and improvements that almost make me feel that the fine folks at Google read my blog, or at least are inside my head, reading my thoughts - which is entirely plausible too.

Check out the full release notes here

Of special interest to me are:

• Better, automated jar dependency support: link
• "Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfigcontaining a DEBUG constant that is automatically set according to your build type." While this does not address my grievances, it's a step in the right direction.
• Hardware virtualization support for emulator images based on x86, link. I haven't tried it out yet, but I'm keeping my fingers crossed that this gives a much needed shot in the arm (see what I did there?) to emulator performance. *And yes, I know my pun didn't really make sense.
• Support for hardware GPU on the emulator: link. This is a big one!   Maybe the openGL support is better on the emulator now too.
• Fixes for Proguard, with the "Conversion to Dalvik format failed with error 1"issue fixed. I wasted an entire evening and then some on that once, though I eventually fixed it by splicing a newer version of proguard into my local ADK.

I have a new version of Sedition almost ready to go, with only minor tweaks needed (most of the time needed will be QA'ing my tweaks). I think I'll wait until I publish again before kicking the tires on this release.

--P

New Graphical Programming Tool for Arduinos

I've mentioned before that I'm a beg fan of the graphical programming paradigm as an educational tool.

Ardublock:

http://blog.ardublock.com/

Is probably the most exciting embedded development "GP" tool I've seen yet. It's well done, and it integrates into the Ardiuno IDE very nicely.


--P

Scala and Random musings

I've always been a programming language geek. I love learning new programming languages, though C++ and C# (and to a lesser extent Java and Ada) have paid my mortgage over the years.

I'm more of a fan of statically typed languages, but when I have to, I can feel my way around Python. Windows Power Shell is also a fantastic dynamic language that doesn't get the credit it deserves. I'll admit the syntax can take a little getting used to, and if you don't use it frequently, you will forget a lot of it.

For a reason I can't remember now, I recently read about Scala. (Wikipedia) I'd heard its name thrown around for a few years, but never really looked much into it. If a language is not available for production use for me, I have a little less incentive to check it out. Scala's primary platform is the JVM, and it can also run on Android's Dalvik without too much fuss. There is a .Net variant that uses the Java-.Net bridge/abstraction framework IKVM, but it is apparently not quite ready for prime time.

Faster horses couldn't drag me away.

Henry Ford once said: "If I had asked people what they wanted, they would have said faster horses".

The profound truth to this is that 'customers' are often much better at describing their problems than coming up with solutions. Engineers too often are better at coming up with solutions than they are in seeing the true problems. The key to getting things done as an Engineer is to recognize when you are attempting to make a faster horse instead of inventing a car. You have to work with your 'customers' (be they clients, other departments, or even other engineers, consuming your code), to come up with the solution that matches the right problem.


I have thought this for a long time, and I blog about it, but I do it too all the time. It's very easy to fall into a trap, it's often hard to tell when you're building faster horses until your halfway done building them. Customers often give you a solution instead of a problem ( eg: "I need a file browser with twelve bookmark buttons", instead of "I need a faster workflow for frequent opening of files"). It's all to easy to build that fancy file browser, only to find out later the button for launching the browser was nested too deep in the UI, and moving it would have solved 99% of users problems.

--P

Sedition

After many months, and even a good deal of schedule slippage, I uploaded my game, Sedition, to the Android market. You can find it here:

Sedition Ad-Supported  and  Sedition Ad Free

I also have a Blog dedicated to my software endeavors, DigitalPopcorn

My baby

(Apologies to anyone reading this who might not be able to access it in the Android Market, I plan to expand offer to additional countries soon, as well as other distribution channels.)

Anyways, it is still in "Beta", but here is a run down of some of the technical/design details of it:

Android Library Management for publishing multiple editions of an android app

[UPDATE 12/30/11: This post is a little out of date, I recently updated to r16 of the ADK, and eclipse 'Indigo' (3.7). I had to play around with the library settings to make the dex process happy, and the settings actually make a little more sense now. I'll make a new post]

Sorry for the long title, but I spent a frustratingly long time( hours ) doing something that should have been achievable in seconds.  My hopes are that I am able to document the steps needed here well enough that someone can save themselves some time.

As a last step before publishing, I needed to be able to quickly make two versions of Sedition, an Ad-supported version, and an Ad-free, paid version. In the Android market applications are distinguished from one another by the "package" property in your AndroidManifest.xml file. So simple, change your manifest name and re-build. Not so fast, the resources in your application, eg the files that get assigned an id in the infamous "R" class, are built to live in that class. So when you change your package, any code that references anything in your R class will break. For me this resulted in over 100 errors. I have some final static variables in that help me define code behavior for any given flavor of build. This was the closest I ever got to a #ifdef type mechanism that I mentioned a few months ago. Unfortunately, there is no solution for changing manifest files in a similar manner.

The conventional wisdom of the Web suggests moving your application into an android library, then make two new "Applications" that then link to the library, like so:

This is what I did. It should, by all accounts, have been quick. It wasn't, there were a ton of booby traps, and unless you have innate knowedge of the inner workings of the android build tools, it's a little bit of a mysterious beast. Here's what I did:

VDHL

I got a chance finally to play around with my Papilio One board, and the Button/LED Wing I got.

I'm fascinated by VHDL, though I'd consider myself a 'novice'. 

I think something may be amiss with my board, or the wing. 

I wrote some trivial 'hello world' VHDL, I made a component that I can "wire up" (technical term) to either the high side or low side of a wing. (The Papilio has 3 16 bit wing sockets, but the Button Wing is 8 bit, and can occupy either half of a wing).

So my component looks like this:

Pre-shaved Yaks.

I wanted a way to keep track of bugs in my Android Game (I know, I promised a big reveal, it's really soon). I'm getting to the point that I have tons of loose ends and TODO's that I wanted collected in a central location. I am a one man dev team, so I thought I'd keep it simple and just use a spreadsheet. That fell apart before I really got started. I once worked on a project, right out of college, a long time ago, that used a spreadsheet in source control to track bugs. It was as bad as it sounds.

Anyways, there are a number of open source bug tracking systems out there. Almost all are web based. I'm not a web-developer. Every time I try to do something that involves setting up a web server, it's a frustrating exercise in shaving yaks.