1. Make sure you have sun java installed (not open).
2. Extract the zip into /usr/lib/
3. Then, a work around is necessary in order to get the menu working right under Unity. Create a script with this in it:

   #!/bin/bash
   export UBUNTU_MENUPROXY=0
   ./AptanaStudio3

The jQuery solution looks like this entails using the very messy looking jQuery() instead of $() because of drupal:

// check that the document is loaded before initiating changes
jQuery(document).ready(function()
{
  // select the element you want to change,
  // in this case our input with id #edit-search-block-form--2
  jQuery("#edit-search-block-form--2")
    .val("Search...")                                             // change the value to Search...
    .css("color", "#b1b1b1")                                 // and the color of the text to whitish according to the needs of my theme
    .focus(function(){                                          // if in focus, we want to change some properties
        jQuery(this).css("color", "black");               // black so the user doesn't have to squint at the text they're entering
        if (jQuery(this).val() == "Search...") {        // if it's still Search, delete that punk
            jQuery(this).val("");
        }
    })
    .blur(function(){                                            // once back from the anarchy of being in focus
        jQuery(this).css("color", "#b1b1b1");          // set the color back
        if (jQuery(this).val() == "") {                     // and replace our trusty Search...
            jQuery(this).val("Search...");
        }
    });
});

The reason this is wrong is because Drupal is already building this form from scratch with the form api. jQuery is coming in after the fact and wasting our users precious processing power. The correct way to do it is to intercept the form during preprocess, and in my case in my template.php, and attach the javascript functions then.

Better tidbits:

AST Evaluation grammar
Parser/Lexer grammar

Business Logic Layer and the Toggle interface control implementation of IMeta

More explanation to come soon.

Play music to fully enter the lair.

The Beast, to those that know her, is a notorious, merciless home wrecker. In a fast paced game of cards, the odds drift elusively in your favor, and then, the beast takes off an arm. Taming her is a challenge worthy of today’s cell phone gamer.

That was the tag line for my newly-open-sourced cell phone game, The Beast!

Source code at the github repository
       »  the core engine loop
The latest build (zipped .jar)

The project was done in Java and essentially just virtualized a game my friends and I used to play in college (think lots of raucous yelling about the Beast every time someone lost). Before I started I drew up a design document and did all the regular rigamarole of game design. It is functionally complete, but a little rough around the edges. The first thing that you will notice is the cpu timing. My modern emulator made input a little lurchy because the processor was doing too many ticks/ms. The good ol’ days that weren’t so good.. This project was a great learning opportunity for both minimalist programming techniques and how to scale a program with limited resources. It also makes pretty nifty use of vector graphics. I’m glad it’s finally getting shared.

An Android refactor is coming, so stay tuned.

Main menu

player selection screen

Prompt for player to make a bet

This player is betting! Pressing select here would bet 3.

the ai gets a chance to play

Notice how the cards slide to their respective sides of the "table".

If a player gets an ace on their first card, they get to choose whether it's low or high, if it's the second card it's automatically high.

The Beast wins! Little surprise there!

You were one of the lucky few to slay the beast!

Today, I loaded up my billing parser and saw this:

void LoadSpreadsheet()
{

var connectionString = string.Format("Provider=Microsoft.Jet.OLEDB.4.0; data source={0}; Extended Properties=Excel 8.0;", _filename);

var adapter = new OleDbDataAdapter("SELECT * FROM [Sheet1$]", connectionString);

var ds = new DataSet();

// grab our spreadsheet data from the adapter

adapter.Fill(ds, "Activity Number");

// now, make it enumerable

var data = ds.Tables["Activity Number"].AsEnumerable();

// grab our data fromt he spreadsheet data with a LINQ query

_query = data.Where(x => x.Field<string>("Activity Number") != string.Empty).Select(x =>

new ActivityStruct

{

activityID = x.Field<string>("Activity Number"),

lineItem = x.Field<string>("Product Line"),

install = x.Field<string>("Order Sub Type") == "New Install"

});

List<string> uniqueActivities = new List<string>();

List<string> uniqueItems = new List<string>();

// populate a list of unique activities

// TODO: Figure out a way to do this and uniqueItems with one pass, // leaving it the way it is now because of time table

uniqueActivities = (from x in _query

where x.activityID != null

select x.activityID).Distinct().ToList();

uniqueItems = (from x in _query

where x.lineItem != null

select x.lineItem).Distinct().ToList();

// TODO: This status text system doesn't seem consistent with the MVVM pattern, look into it

OnPropertyChanged("StatusText");

_spvm.AddItems(uniqueItems);

_spvm.OkPressed += this.OnPricesFinalized;

}

Seeing this made me do this:

the bad code face

There’s multiple problems with this but let’s start with the most obvious:

1. Lots of unnecessary looping.
2. Redundant data.

Not to mention it’s ugly. I knew this when I wrote it (the TODOs made me laugh, may as well say DISCLAIMER) but was under time constraints so just wrote it like it was a python script and made sure it worked. But it’s not OOP at all and takes really bad advantage of referencing, and the rest of the program deserved better. The refactored LoadSpreadsheet method builds the model tree structure in one pass.

void LoadSpreadsheet()
{
var connectionString = string.Format("Provider=Microsoft.Jet.OLEDB.4.0; data source={0}; Extended Properties=Excel 8.0;", _filename);

var adapter = new OleDbDataAdapter("SELECT * FROM [Sheet1$]", connectionString);
var ds = new DataSet();

// grab our spreadsheet data from the adapter
adapter.Fill(ds, "Activity Number");

// now, make it enumerable
var data = ds.Tables["Activity Number"].AsEnumerable();

Dictionary<string, LineItem> uniqueLineItems = new Dictionary<string, LineItem>();
// iterate through every line of the excel table
foreach (var x in data)
{
// get the raw strings from our data, used for dictionary keys and model unique IDs
string lineItemID = x.Field<string>("Product Line");
string activityID = x.Field<string>("Activity Number");

// make sure our line item and activity string aren't null
// if line item is null, we don't really care about the entry
if (activityID != null && lineItemID != null)
{
bool isInstall = x.Field<string>("Order Sub Type") == "New Install";

// see if the new line item is already in our unique list
if(!uniqueLineItems.Keys.Contains(lineItemID))
{
//instantiate the new line data we're going to add to our tree structure
LineItem newLineItem = new LineItem(lineItemID, 0);
// add it, referencing newLineItem.Name saves redundant data
uniqueLineItems.Add(newLineItem.Name, newLineItem);
}

if (!_activities.Keys.Contains(activityID))
{
Activity newActivity = new Activity(activityID, isInstall, uniqueLineItems);
// we add the new activity to the list using the same method we used earlier with lineItem
_activities.Add(newActivity.ActivityNumber, newActivity);
// passes a reference to the uniqueLineItems instance of our object
// that way, when it updates from the VM data bind our models auto-update
_activities[activityID].AddLineItem(uniqueLineItems[lineItemID]);
}
else
{
_activities[activityID].AddLineItem(uniqueLineItems[lineItemID]);
}
}
}

_spvm.AddItems(uniqueLineItems);
_spvm.OkPressed += this.OnPricesFinalized;

// TODO: This status text system doesn't seem consistent with the MVVM pattern, look into it
OnPropertyChanged("StatusText");
}

Now, one thing I still failed to do was to implement HashSet. HashSet, at first glance, looked perfect for my needs in this case. I needed a unique list and the models contained within the collection already had unique identifiers. Unfortunately HashSet in .net 3.5 is designed for immutable objects (based on its math counterpart no doubt) and the generic derivative of it I made ultimately wasn’t as clean as just using a dictionary because it would’ve meant I had to implement IEquatable on my model classes, which as a general rule I don’t do because they’re mutable and you don’t want the wrong class (or worse, programmer) to think an instance is equal when it’s not. I think I actually might of even gone down that path a bit when I first worked on the project but decided to forget it because I realized it was going to be a time sink. The solution turned out to be super simple! By using a Dictionary with the string linking to the model.uniqueID. This gave an easy lookup within the loop without any data structure and memory redundancy, which for whatever reason still bothers me despite having 16gb of ram. Cell phone development 4 life!

The other change you’ll notice was I passed a copy of UniqueLineItems to both the SPVM and our models, which acts as a master list of objects. In activities, in order to track the quantity of items each activity had, I implemented a Dictionary, with the LineItem being a reference to the instance within the UniqueLineItems collection and the int being the quantity of that item. This saves a lot of code.

// ..........
// client gets a free receiver install with the price of an install
bool installReceiverNotPaid = true;
//now we process the line items for value
foreach (var item in itemQuantities)
{
// if there is a quantity associated with the item (should never happen)
if (item.Key.Value != 0)
{
// now we iterate however many times the item appears in the activity
for (int individualItem = 0; individualItem < item.Value; individualItem++)
{
// if activity is an install, item is a receiver, and we haven't already acknowledged the first receiver
if (_isInstall && installReceiverNotPaid && item.Key.IsReceiver)
{
Debug.WriteLine("First receiver accounted for.");
// value remains the same
installReceiverNotPaid = false;
}
// this catches everything else for both installs, upgrades, non-first receivers
else
{
Debug.WriteLine("Added " + item.Key.Name + ": " + item.Key.Value);
value += item.Key.Value;
}
}
}

Any feedback, as usual, is welcome.

The problem:

A Directv installation company recently hired me because they had a problem: they get paid in bulk and really had no idea what they were getting paid for because their client was just handing them a check. The only thing they were given as an invoice was a normalized database dump. They had no idea what to do with this information so asked me to write something that would tell them exactly how much they were supposed to be paid. Stripped of any proprietary information, the database dump looks like this with approximately 2000 more entries:

Notice the conspicuous lack of basic things like amount paid per line item. They knew how much they were supposed to get paid per job, but with just the individual line items in a big list it had to be extrapolated from the data given by the client. What further complicated matters was that the prices for a given line item isn’t entirely consistent, it would depend on the type of job done (upgrade or install) how much you got paid for a particular item. I also wanted to give them the ability to input that information since the prices they were paid could change in the future.

The Solution:

A WPF project based on the MVVM design pattern.  This afforded several advantages:

• tidy seperation of concerns and interface driven
• easy to solicit user input at run-time due to good data binding support in WPF
• xaml interface creation allowed me to make a fluid, robust interface in a short amount of time
• Automatically generated documentation
• .net gave me access to OLE-DB for easily parsing the excel files

I started with normal MVVM stuff like rerouting the App code-behind to my primary ViewModel, named MainWindowViewModel, which derives from ViewModelBase, giving us access to INotifyPropertyChanged, and virtual string DisplayName.

void AppStartup(object sender, StartupEventArgs args)
{
MainWindow window = new MainWindow();

// Create the ViewModel to which
// the main window binds.
var viewModel = new MainWindowViewModel();

// Allow all controls in the window to
// bind to the ViewModel by setting the
// DataContext, which propagates down
// the element tree.
window.DataContext = viewModel;

window.Show();
}

The main window itself consists of 3 controls: an open spreadsheet button, a status text to give user feedback, and a third area for user input of prices. The open spreadsheet button opens a file dialogue and is data bound to class that implements ViewModelBase and contains an ICommand field. This is essentially just a relay command that gets delegated to a private method within MainWindowViewModel and makes sure the interface stays abstracted from our implementation. The StatusText is just a string property that updates according to various state triggers. I’m sure there’s probably a better way to handle this in .net but haven’t had a chance to look into it, yet. The ContentControl is bound to a property called Spvm (SelectPricesViewModel), with its visibility tied to an “IsPopulated” boolean. This checks if the spreadsheet has been opened and passed a unique list of items. So, by default it is not visible (not collapsed, however the data isn’t there yet so it will expand once the data populates):

The default state of of the application before opening a spreadsheet.

SelectPricesViewModel contains a list of unique line items, queried and passed from MainWindowViewModel:

 uniqueItems = (from x in _query
                where x.lineItem != null
                select x.lineItem).Distinct().ToList();

Subsequently, there is also a model LineItem and LineItemViewModel. LineItem contains very little business logic, but does provide a value, name, and whether or not the line item is a receiver or a “OneOff”, or in other words counted only once per activity. LineItemViewModel just mirrors LineItem but calls NotifyPropertyChanged() where appropriate. SPVM uses an ObserveableCollection of LineItemViewModels to populate a data template contained within MainWindowResources and solicit input from the user. I did have a user specified IsReceiver boolean within the ViewModel (which I left notify capable) but have since edited that to be accomplished programmatically with a regular expression checking for the keyword “IRD” in the line item name. Here’s how it looks after the spreadsheet has been loaded and SPVM is populated and visible:

State of the program after the spreadsheet is selected.

The user then uses our “compute” button (a CommandViewModel) to trigger an event which is routed within MainWindowViewModel to our OnPricesFinalized private method. This basically just iterates through the activities from the database query, matches them with the prices from the SPVM, and has them calculate their own prices. The activity value algorithm looks like this:

public double Value(double PriceOfInstall, double PriceOfUpgrade)
{
    double value = 0;
    Debug.WriteLine("Activity #" + ActivityNumber);

    if (_isInstall)
    {
        Debug.WriteLine("Install - Value: " + PriceOfInstall);
        value += PriceOfInstall;
    }
    else
    {
        Debug.WriteLine("Upgrade - Value: " + PriceOfUpgrade);
        value += PriceOfUpgrade;
    }

    bool skippedOne = false;
    // Populate a dictionary to track one-offs, bool is true if the line item
    // has already been counted
    Dictionary OneOffTracker = new Dictionary();
    foreach (LineItem li in OneOffLineItems)
    {
        OneOffTracker.Add(li, false);
    }
    //now we process the line items for value
    foreach (LineItem li in LineItems)
    {
        if (li.Value != 0)
        {
            if (li.IsReceiver == false
                && li.SkipDuplicates == false)
            {
                value += li.Value;
                Debug.WriteLine(li.Name + " - Value: " + li.Value);
            }
            else if (li.SkipDuplicates == true &&
                !OneOffTracker[li])
            {
                OneOffTracker[li] = true;
                value += li.Value;
                Debug.WriteLine(li.Name + " - Value: " + li.Value);
            }
            // if it's a SkipOnInstall item, check to see if one has
            // already been skipped before adding the value
            else if (_isInstall &&
                !skippedOne)
            {
                skippedOne = true;
            }
            else
            {
                value += li.Value;
                Debug.WriteLine(li.Name + " - Value: " + li.Value);
            }
        }
    }
    Debug.WriteLine("TOTAL VALUE: $" + value);
    Debug.WriteLine("");

    return value;
}

That’s the guts of it. Note that the first receiver in an install does not receive payment, it’s included in the cost of the install. After iterating through all the unique activities, the status text is updated with the cumulative value and subsequent spreadsheet reloads clear out the unique items from SPVM.

On a side note, I don’t quite understand why Steam doesn’t do this already. Anything that brings third party developers closer to consumers is kind of Valve’s thing. I really need to touch this thing up and publish it.