Robinhood CLI

Five seconds to a buy order

Links: Download (build Aug 25, 2016) - Source Code

Robinhood CLI (rh-cli) - a simple (unofficial) Windows command line client for Robinhood that no one asked for.

Despite being command line, it's more focused on usability than automated trading, and attempts to reduce the time to place a trade to that of other trading platforms, helping to avoid possible price fluctuations in between.

I mainly use this project as a means to get myself into C# programming (making something that works and is something people will use irl) and to learn the more advanced aspects of that language (such as asynchronous programming and parsing json files), but it might be useful to a number of people.

I intend to add features to this program for at least several more months while I'm still looking around for a full-time software development job; feel free to point out any changes made in the backend that prevents this program from working, or any corner cases that I didn't check (such as whether rh positions with > 150 stocks owned will fail to load (either partially or at all), because URI length > 8k ).

Features

This program adds a number of things not seen (afaik) in any other unofficial RH implementation. This list will be added to as time goes on.

• Increased Realtime Quote Speed - Increased the update time to once per second (this is slightly faster than the update speed on Google Finance), particularly since battery drain is not a real issue on a PC. This is around 5x the speed which Robinhood updates. There might be rate limits, but so far I haven't hit any of them. (If you have a lot of stocks up at one time then updates are slower)
• Margin Buying Power - Displays how much actual buying power you have in your account in an Instant account. In Robinhood Gold accounts, this also factors in extra buying power based on the tier you have subscribed to, although you will be informed if you cannot use all of it when buying that stock. (A number of assumptions were made on how margin is implemented, so this value may be inaccurate)
• Maintenance Margin / Initial Margin - Gives you information on how big of a position you can open when extra buying power from RH Gold is considered. (We assume that "extra buying power" represents additional funds handed to you by RH, and are subject to margin requirements). If either of these percents are above 50%, you might not be able to utilize all of your extra buying power on that stock. The official app will adjust your buying power accordingly but will not give you exact margin requirements.
• Intraday Buying Power (Day Trading Buying Power) - Determines how much you can trade during the day. It's based off of 4x excess margin, so accounts comprised of blue-chip stocks (example) will have substantially higher buying power than those who are mainly holding low-priced and/or volatile stocks (example). On non-PDT accounts, you may start getting High Volatility warnings once you go negative; you will receive a Day Trading Margin Call if you are flagged as a PDT. Buying leveraged ETFs will reduce this faster, so your intraday buying power will be adjusted accordingly. (The app will limit your buying power to prevent this, and does not make any mention of DTBP at all, except in Disclosures.)
• Max Buy/Sell: Tells you how much of that stock you can buy right now given your buying power, as well as how many shares you have currently and in open orders. (If the price does move past 5% between when you entered the command market orders may not fill). Currently this does not factor the max amount when you place a limit buy order, so be warned if you are planning to spend to the last penny.
• Stock Split Indicator - If your shares vanished (or were adjusted) because of a reverse stock split, didn't see a notification regarding this (or never got them), and it happened within the last two weeks or so, you will know now. (If you don't have enough shares to meet the reverse split ratio, they are usually converted to cash.) You will also be informed if the opposite holds true.
• Fees Paid if Applicable - If you are charged a fee when the order is filled, it will inform you. The commission might be zero but the regulatory fees aren't. This fee is more noticeable when selling tens of thousands of dollars worth of shares at once. (FYI: For options, the cost from options regulatory fees alone bumps the total fee to 4 cents a contract, whether you are buying or selling, so make note of that when they support options trading.)
• Account / Portfolio View - You can display either basic account info and/or a list of all your stocks in your portfolio (including quantity held, equity, cost basis, current price, and profit/loss so far) If your portfolio consists of a lot of stocks it may take a while to load.
• Extended Hours Trading - Allows you to choose whether your orders will be active during normal market hours or extended hours as well. RH Gold has no setting to toggle this off, so this might be useful in some cases.
• Additional Warning Messages - Because you are using an unofficial app you may be able to get by some of the restrictions that the official RH app has set in place should those orders fill, so it is my responsibility to cover these scenarios. There is one additional warning if the limit price you are entering is substantially lower than the current price.

  Also, market sell orders executed on this program will not execute if the price would be below 75% of current price (most likely due to significant slippage), at which point you should do a limit sell instead.

Project: Unofficial Robinhood (Web) App Development

When I need more info and a substantial decrease in latency when making trades.*

The lack of non-mobile trading options on Robinhood has led to a large amount of unofficial implementations (most on Github) that allow you to trade while away from a smartphone (other than using an emulator), however a majority of them cover only basic functions to do trading (such as buy/sell stock, get quote information). Seeing an opportunity to enter into the field of web application development, I decide to join in as well, believing I can bring something new to the table.

My first open-source (and real C#) project starting my Github programming portfolio involves use of the console to assist with active trading utilizing the RH API. You still have to manually enter your orders, but it's able to enter positions faster (mainly by skipping the Trade Preview step).

This program was based on other open-sourced apps that used the API; I don't know why most of these implementations have been largely abandoned in recent times, but I guess I'm about to find out.

Github source for the above available here.

Please note: This project exists mostly as a coding portfolio piece; I only have part-time working experience but completing this might get me much closer to getting my foot into the door somewhere.

Progress:

This project is divided into four segments:

• Robinhood API docs: A forked version of an existing RH API documentation with more endpoints filled out and more focused on consistency.
• RobinhoodNET: A C# .NET API that allows easy access for most parts of the RH API.
• rh-cli: command line interface to get various quote information, buy/sell stocks, and a few other things. Stock quotes are updated once per second while placing an order.
• rh-alt: Alternate* Web Client interface (might be coded with a combination of Angular.JS, Javascript, HTML5 canvas, d3.js, and more)

Superhuman, Chess Pieces, and Binary Code

Zoe - Binary Wizard - computing her King & Queen challenge on #Superhuman! pic.twitter.com/cBHjb8SBqB

— FOX (@FOXTV) January 5, 2016

The first performance of the Jan 4 premiere of Superhuman has Zoe Wheeler reciting from memory the sequence of 60 chess pieces (30 white, 30 black). Only there are two types of pieces to memorize: a King (White) and Queen (Black). A 0 or a 1. Binary Code.

Although there are over 1 trillion combinations (more like 118 quadrillion) that figure need not apply here.

Memorizing 60 1's and 0's might be a difficult task, but there are ways to cut down on the memorization significantly.

There are various methods of memorizing groups of binary code, including hexadecimal (grouping four 1/0s together to get 0-9, a-f), and base64 (grouping six 1/0s together to produce a letter or a number). I use the latter since I can memorize a string of 10 letters/numbers easier than other options.

Base 64 Summary:

A set of six 0 and 1's (64 possible combinations) are grouped together to form a single letter or number (A-Z, a-z, 0-9). Two more characters are used for the binary values of 63 and 64 since the total number of letters and numbers = 26+26+10 = 62. There aren't a string of seven black/white pieces in a row, so they can be skipped for the purposes of memorizing this.

Solving:

The order the pieces are laid out are as follows (Treating a white piece as a 1, with the piece closest to her as the first):

100101 001001 010010 001001 010100 111010 110110 001010 111001 101101

This can be encoded to base 64 as follows:

37 9 18 9 24 58 54 10 57 45
kIRIT 51J4s

Now it's a matter of memorizing this string, converting it back to binary, and reciting it... in front of a live audience.

Americana Engine: Redesign

Minor (but important) differences in the script syntax from Beta 3 -> 5, especially for branching statements.

A number of changes have been made to the underlying code as well as scripting format in order to both improve readability and performance. Compiled maps from Engine Beta 3 or below* may not be playable since a lot of crucial triggers will not work properly, making Beta 4 the last official version for backwards compatibility. For more information on what may appear in Beta 5, see the changelog.

Brief list of changes:

• All resources now load outside triggers instead of as actions.
• Strings are now compressed for standalone maps
• Map variables now include strings as well
• Variable pointers are used at the beginning of a variable instead of extra values on an action
• Jump Actions now made into If-Then statements by default
• Locations were reworked
• A lot of internal code was refactored

Next:

• Faster map reloads
• New GUI for terrain editing

Development Comments:

Loading resources were originally placed in triggers since there was originally enough of them would cause lag if they were placed at the beginning. After some consideration, not only does sounds and resources loaded in the middle of a map cause a few inconsistencies, they can also break some parts of a map if a trigger that loaded them happened to be skipped over for some reason, and another trigger loaded them instead. Additionally, loading in the middle will also lag for the time the texture or sound loads in realtime, and is more significant if the file being loaded is large. It's not going to make a difference in compiled maps, since all of the data is loaded at the beginning.

To centralize the location where all resources will be loaded, all resource calls are now outside triggers, and there should now be no question as to where these statements can be placed and if they will run or not.

Jump Actions were implemented because of the way the script was interpreted; You needed to get to a line, and there's a trigger to do so. Originally the jump statement required a number and optionally direction (up or down). During early stages of beta testing, users had difficulty with figuring out where these statements were jumping to, and most of the time was spent fixing issues and having to readjust the code every time a line was added in the middle. I also did not want to promote bad programming practices, and this one did it with spaghetti code. The problem was resolved with conditional statements instead. Jump to line is still there, just using labels now.

A bunch of code was refactored (and placed into separate source files) since it became progressively harder to add new features, and even more so to maintain. Prior versions placed most of the map rendering and editing functions in a single cpp file, and class definitions in several other header files. It was nearly impossible to split the main cpp file up as class methods pulled data from global variables. In larger teams, the same cpp file was being edited, which can get extremely cumbersome as all revisions from each commit had to be merged and reviewed so that it didn't cause conflicts and/or errors in the source file, as well as other classes referencing it.

The Battle Simulator in previous game engine releases is not compatible with the current engine version and will not be included in release builds, however source code for the map will be available as a separate download for anyone interested in updating it.

WIP: Americana Engine Beta

Project page styled with a (modified) legacy AD template

With a growing amount of software development jobs favoring a portfolio of prior work over just a resume, I have proceeded to showcase a few pieces of work of my own.

Summary

The Americana Engine is a ongoing game engine project started in 2013 running under Windows. It was originally developed for Americana Dawn to get past a lot of the limitations that RPGMaker had (which the game was originally developed in), adding a higher resolution, finer sprite control (not having to rely on parallax mapping), map portability, and adding native functionality for the large-scale battle system.

The Lead Programmer's version of the game engine (including the editor used to make maps) is now available to the general public, adding a number of enhancements and fixes complete with development notes and custom maps, and is being actively maintained. More information on this can be found on its project page.

Brief Notes: (at the time of writing)

• The engine is currently in active development, and may contain bugs or unfinished features. You are free to discuss it or report any problems, questions, feature requests, etc. at forums.bitbonton.com for now. If you want to directly contribute to the codebase, send a email to me directly.
• Scripting documentation and tutorials will be provided in the near future.
• No assets will be included except for those used for in-game GUIs.
• The engine can run maps from Americana Dawn with limited support, however you will need to provide those maps. Maps previously available to beta testers are included in this zip file (for demonstrating the engine as a portfolio piece), with a number of improvements.

Americana Dawn: Kickstarter

Brief Summary:

Americana Dawn is a role playing game that takes place in Colonial America inspired from the Suikoden series of games. It emphasizes more on tactics (instead of level grinding), exploration, and a variety of large scale battles.

Almost after two years of developing a custom game engine for Americana Dawn, the Kickstarter is ready to go.

Although the Kickstarter has ended unsuccessfully, it has been Greenlit on Steam so there's a good chance it will be made available there in the near future.

Notes:

• The battle scenes are part of the battle simulator, which generates random encounters as well as showcasing new battle features. It is undergoing testing and will be released at some point in the future when the demo is out. As this is a dev created map, expect a lot of references in it.
• The World map is explorable, though where you can go is quite limited at the moment. This region expands as we go along.
• There will be a later post covering the various features the game engine can do in battles as there were a few things that I wanted to demonstrate, but might not be utilized to their fullest potential in the beta / demo versions.

Americana Dawn: Microbattles

A Staresque Ring on Foster could've brought him back up, but they're quite expensive early on.

A Microbattle in AD is the game's battle system and the main way to resolve conflicts. From a distance and from screenshots, just like ordinary battles you see in other JRPGs: Turn based combat, characters using skills and items on the field, etc.

Beyond that, the similarities end here. Other than a few functions which handle battle related units (such as stats, learned skills, and equipment), what exactly occurs in the battle is based on map implementation. Want to have a simple skirmish vs a few soldiers? That works. But for those who demand more creativity (like me) I focus on a few other mechanics it can have:

• Units have both HP / willpower. Your characters (including enemies) will regenerate their HP once they're down or in cover, but further attacks on them when incapacitated will drain their willpower, which doesn't come back on its own and increases the amount of damage they take in combat.
• Each character has carrying capacity, which limits the amount of items they can carry at one time.
• Pardoning. Because killing enemies isn't the only way to resolve a conflict. Some events in the game may change based on your decisions.
• Passive environmental effects, meaning some weapons can be less effective in an area.
• Interactable objects. Sometimes the method to defeat them isn't as direct as it seems.

Note on Commands: Attack / Defend are not simple one-off commands, since characters usually have more than one attack type available. Example: If Foster has a musket, he can either fire (at reduced accuracy) or engage in close quarters combat and use it as a melee weapon.

Handling Diagonal Movement in Tactical RPGs

Ignore the Battle GUI - it is a mockup and therefore has incorrect information.

Normally Tactical RPGs do not allow diagonal movement, however I propose a system that handles this while factoring in obstacles.

While designing the war system in Americana Dawn, there were previously a few issues about the move range on a character; because the shoot distance is calculated by absolute distance from the character (instead of grid squares) it would create a disadvantage for some units. Also, it creates movement range more like a circle.

If a melee attacker was hit from a diagonal, it would normally take two turns for it to reach the target. The extra turn is a huge difference - the attacker that could otherwise defeat the enemy may not survive the second turn.

I had a few choices, either restrict attack range, or include diagonal movement. Moving based on absolute distance was considered, but it was ruled out since it can get messy at times and might not find the optimal route when tiles are weighted. So a diagonal is calculated as 1.5 movement points. (It might be 1.4 movement points later if the game requires more precision.)

But this is not factoring in the weights of the various tiles, so this is achieved by taking the weight of the diagonal square that you move to, plus the two adjacent squares that you cross getting there, and dividing by two. Thus the formula is:

Movement Cost = (Tile Weight for upper right tile + upper tile + right tile) / 2, relative to the character.

There's situations where a diagonal move takes up more move points than moving two spaces instead, but the game automatically calculates the shortest distance to a tile anyways so it isn't a real problem.

The drawback is being able to get to normally inaccessible tiles via a diagonal move. Consider it as an advantage - the 'creative designing' process should ensure this happens only when it needs to.

I think more of the creative designing should be the AI script for these battles, which is mostly based on the enemy commander's personality, although it usually looks ahead at least a turn and makes decisions only based on what it can see, and will find cover and ambush if possible.

Programming Keyboard Movement

After days of figuring out the logic behind mapping key presses to moving backgrounds and sprites, I have a somewhat functional copy of the game engine - so called Banana Slug*. Characters can run using the shift key, although how many characters have running animations is strictly based on budget.

This code is so complex - maybe 150 lines to control basic map and character drawing functions. And we still have a variety of sprite overlays to draw as well as anything menu and dialogue related, as well as reading scripts from an external file. Lots of math involved in manually calculating the draw positions and figuring out an equation for this. Good thing I took those applied math courses.

Keyboard Movement Code

This modifies the dxinput.cpp and dxinput.h file found in the book Beginning Game Programming, 2nd Edition by doing the following:

• Assigns key_lock[256] as a bool array.
• Modify Poll_Keyboard() to be the following:

  
  void Poll_Keyboard()
  {
   if (dikeyboard != NULL)
   {
    HRESULT result; 
    result = dikeyboard->GetDeviceState(sizeof(keys), (LPVOID)&keys);
    if(FAILED(result))
    {
     if ((result == DIERR_INPUTLOST) || (result == DIERR_NOTACQUIRED))
     dikeyboard->Acquire();
    }
    else 
    {
     for (int i = 0; i < 256; i++)
     {
      if(!(keys[i] & 0x80) && (key_lock[i]))
       key_lock[i] = false;
     }
    }
   }
  
  }
  

• Added a Key_Down_Once function:

  bool Key_Down_Once(int key)
  {
   if ((keys[key] & 0x80) && (key_lock[key] == false))
   {key_lock[key] = true; 
   return true;}
   else return false;
  }
  

• Adding the function prototypes in the header file

When the keyboard is polled, it will check to see if the keyboard is acquired (via GetDeviceState) and if it isn't it will attempt to reacquire it. The keyboard is automatically unacquired when the program loses focus and without this addition, the program will no longer receive input from the keyboard. (Code regarding reacquiring input devices aren't covered in the 2nd edition in the Game Programming book, and although a similar function appears in the code on the CD in the 3rd edition, it isn't explained anywhere in the book.)

If the keyboard is already acquired it will check the state of the keyboard and will disengage the key_lock if it was set and the key was released.

Key_Down_Once will set the respective key to its locked state and register the button press, it will not register that key press again until the key is released. This was needed since the original Key_Down function will keep registering a button press as long as the key is held down (as in triggering it as fast as the program allows) - it doesn't register key presses in the same way or at the same speed as holding down a key on the keyboard (where there is a delay before key presses are repeated). Useful when you have keys toggle certain things.

Americana Dawn: Week 4

Challenge of February: Screen Space and Understanding how this DirectX stuff works. (Photo credit: The Lone CS Major)

Ironically, I would be the one resembling the lone CS major, not him.

Four weeks have gone by since I started the project, and plenty of stuff has gone on during that time. I recruited another developer to help with the project (from CKI, it's the connections btw), and over fifteen whiteboards were filled with game data, skillsets, overall game planning, etc. Work now begins on both the game engine and the editor in question. The game engine, as well as memory management (to ensure the game fits under 200MB, if possible) will make it a real challenge (see note below).

Less than two months to go before that demo rolls out. (The game won't be completed by end of April - though the engine might be completed, the assets for a large scale game probably might not be.)

CS and DirectX: DirectX was never taught in any basic or upper level Comp Sci course that I have taken - at most MFC was introduced in one project and practically everything else was command prompt.

Americana Dawn: Programming Standpoint

First Challenge of the month: Making sure the music from the composer can be played in the game.

The general game flow is mentioned in this post in Bit Bonton.

It was 18 months ago that I made a mention to Americana Dawn, and maybe longer that I was aware of it. In recent weeks, I was asked to help out with the project, which I accepted.

The demo was originally set for July 4 2012, but this was pushed back. Twice. The Kickstarter for the game was successful, but the game went way over budget.

After choosing to commit, two things were realized: One, I can no longer do a review for this game - after all, I am part of the team that makes the game, so I could essentially add features that I would otherwise say in a review as 'not present in the game', and work my way towards an ideal highly rated RPG. Two, this occupies the timeframe of a standard 3 or 4 unit class (has regular meetings, building the game, etc), and the term project for this one is... the completed game (by Apr 28) so I'm in for something new. Like an intern position for an game company, except that pay is based on how much people donate*.

The last time I remember programing something of this depth was three years ago, where my entire class worked on an airplane simulator, and it became the class term project. (It ultimately didn't reach completed status). It's like this now - only it's just me and whatever reference manuals I can find on the internet.

My experience with programming the game will be described in several posts over the next eight months or so, and will fall under the Americana Dawn category.

The App Planning Stages

The requirements for the app were the following (updated as I go along):

• 16-bit style RPG
• Keyboard controlled (I may add mouse support of people ask for it)
• Linear gameplay (although it will be open world to some degree and may have sidequests)
• Dynamic music - ability to change out music on the fly based on location and on-screen events.
• Be able to handle various environmental effects as well as support large map sizes
• Complex Large Scale Battle system (sometimes handling hundreds of units in a single battle at once)
• Deep storyline and character / gear progression system, and ensuring there isn't any excessive grinding.

The program was originally generated using RPGMaker using multiple scripts to handle custom features like pixel (instead of grid) movement and battle systems, but the engine was not geared towards many of the heavy modifications this game would otherwise require, especially the sound and larger character sprites. So I'll have to build a custom engine for this one.

Excel VBA Macros: Borders and Formatting

Borders seem very complicated when you record a macro for borders, do any kind of text of text formatting, etc., and look at it in Visual Basic. There are a few ways to simplify this.

Border Formatting Example

You record a macro, make a selection, and set borders. You immediately get something like this:

    Selection.Borders(xlDiagonalDown).LineStyle = xlNone
    Selection.Borders(xlDiagonalUp).LineStyle = xlNone
    With Selection.Borders(xlEdgeLeft)
        .LineStyle = xlContinuous
        .ColorIndex = 0
        .TintAndShade = 0
        .Weight = xlMedium
    End With
    With Selection.Borders(xlEdgeTop)
        .LineStyle = xlContinuous
        .ColorIndex = 0
        .TintAndShade = 0
        .Weight = xlMedium
    End With
    ...

Need a TL;DR? Essentially it is

1. Removing any diagonal borders through the cell, and
2. replacing each border with a medium size black line.

The details are:

• .Borders(Direction) indicate which border you want changed.
  • xlDiagonalDown affects the line from the top-left to bottom-right of each cell selected.
  • xlDiagonalUp affects the line from the bottom-left to top-right of each cell selected.
  • xlEdgeLeft, xlEdgeRight, xlEdgeUp, and xlEdgeDown affects the left, right, top, and bottom borders of your selection. That means it treats your selection as a box, and the sides are what the code affects, see the above image for details.
  • xlInsideVertical and xlInsideHorizontal affects all the other vertical and horizontal lines (respectively) in your selection that the above didn't cover.
  • If you don't specify a direction, then all
• The parameters you can set for borders are:
  • .LineStyle controls the line style. See the top for details.
  • .Weight controls how thick the line will be.
  • .Color controls the color of the line. You can use RGB format.
  • .TintAndShade controls tint and shade, but they can be ignored if you're using RGB values.

You don't have to stick to just the current selection, it can be modified so that you can change the borders for any cell without having to select it (and there are some good uses for this), so you could substitute Selection with stuff like:

    With Worksheets("Sheet1").Cells(6, 1)              ' This way you can use variables when accessing. 
       .Borders(xlEdgeBottom).LineStyle = xlContinous
    End With

- OR -

    With [D2].Borders(xlEdgeTop)
       .LineStyle = xlContinous
       .Color = RGB (255,0,0)
    End With

Text Formatting

The same can be done with Selection.Font (the parameters above work on this as well). I am listing only important values.

• .Color controls the color of the test (use RGB)
• .PatternColor controls the color of the background (use RGB)
• .HorizontalAlignment controls text horizontal alignment (equal to xlLeft, xlRight, or xlCenter)
• .HorizontalAlignment controls text horizontal alignment (equal to xlTop, xlCenter, or xlBottom)
• .WrapText = (true to wrap)
• .ShrinkToFit = (true to apply)
• .Orientation = (what angle to rotate it by)
• .AddIndent = (true to indent)
• .IndentLevel to determine how far to indent (whole numbers only)
• .MergeCells to merge or remove the merge on the affected cell(s). To not do anything with the cells structure, don't include it.
• .Name = (font name, enclosed in quotes)
• .Size = (font size)
• .Strikethrough = (True to make it strikethrough)
• .Superscript = (True to make it superscript)
• .Subscript = (True to make it subscript)
• .OutlineFont = (True to put an outline on text, but it apparently does nothing)
• .Shadow = (True to put a shadow on text, but it apparently does nothing)

Sharing More Coins Per ZB Post

Note: Solved by daily gifts and message center, which give you 4k per gift received (once per friend, per day).

Previously, people had a much easier time grabbing mojo though conventional methods (mainly through fortune cookies, which through a trick allowed players to collect hundreds of thousands of mojo from a single person), allowing people with just a few friends to play quite a bit with that extra mojo. Now, coins gained are only based off of leveling up and feeds, and top players were mainly determined by those who could collect the most - which meant having to join groups and add tons of fellow players for both competition and coin sharing.

Unfortunately not everyone is comfortable adding tons of strangers in order get lots of coins. Even more are not comfortable about the near requirement of using third party programs to collect bonuses for them.

Solution? More coins shared in fewer posts - it won't have much effect for those with hundreds of Zuma friends, but for players who are only comfortable with a small amount Zuma players on their friend lists, this should even the odds a bit.

Effect: Greatly increases the amount of coins you can share to others per post. You get no additional coins from doing the below steps.

1. Fire up Fiddler, make sure you disable FB Secure Browsing

2. Enter the following, somewhere between the OnBeforeResponse Brackets...

        if(oSession.uriContains("/facebook/zumablitz/ajax.php")
            && oSession.GetRequestBodyAsString().Contains("getZumaSpinResults"))
        {
            oSession.utilSetResponseBody('{"response":{"payoutColumn":10,"consecutiveDays":1}}');
        }

This will make the game think you got 1 million coins per spin (and this is the only payout that allows you to share 4000 coins compared to 1000). However the server will know your true coin total, and will reset to that amount when you refresh.

3. (Optional) Enter somewhere between the OnBeforeRequest Brackets...

         if (oSession.uriContains("/dailyspin.xml")) {
            oSession.url = "bchantech.dreamcrafter.com/zumablitz/custom/dailyspin.xml";
        }

Not required, but prevents spamming others with feeds saying 'I just won ONE MILLION free coins', because you didn't. It connects to my server to get a replacement string file, so if you are unable to load the game, you can omit these lines.

4. Clear browser cache.

5. Start Zuma Blitz (from bookmarks, not via a collect feed). - and keep Fiddler open while the game is running to share extra coins for your spins.

Project: ZB Advanced Extended Stats

Previously there was a Top 200 leaderboard made because the person who made the leaderboards discontinued it, before another person picked it up. Now, we have another program designed to help the needs of the users simply because Zuma Blitz didn't provide it yet.

Enter a program called Advanced Extended Stats for Zuma Blitz: A project that was made because people didn't know how well they did or where their points came from.

Description: Allows you to see your performance history in Zuma Bltz. At the time of writing, the game only gave you your score at the end of the game (as well as your friend's scores and level only), this program will give you a lot more than this. Can also give you board records, average board scores, etc.

This program can also get high scores of other people, even though you aren't friends with them - but only if they are also using this program to record their scores.

Implementation: As of November 4, the program is now available for the general public for use. Access it using this link. FB logins are not present at this time, but it might be in the future to display personalized stats.

Purpose: Another attempt to bring back the Top 200 leaderboard. It's a bit more complicated to use though, but at least players are not pulled in automatically - they instead must choose to op-in into this one.

Excel VBA Macro Basics (Part 1)

The following is a brief guide to VBA Macros in Excel, how to use them, and in my opinion, what functions you should know about. This is one of my first reference pages, so this page might be updated frequently.

Requirements: At least Excel 2007. Other versions of excel might have ways of accessing / running macros differently.

Note: I'm assuming that don't know anything about macros in Excel prior to reading this.

Setup:

Activate Developer Tab: In Excel 2007 Options under "Popular" submenu. In Excel 2010 you'll have to go to the Customize Ribbon and on the right you'll have the option to check the "developer" menu to enable it.

Access Visual Basic: Using the developer tab, click the button that says "Visual Basic".

Create a Module: Modules are used to run functions / subcommands and store code for any macros or button functions. If you record a macro, a module will automatically be created.

Though it is entirely possible to place functions inside a sheet and run it as a macro, it's typically better to store them in separate modules in the document, because if you happen to delete the sheet containing macro code, you'll lose it. Code related to buttons and other controls on the current sheet have to be placed inside their own sheet code.

Selecting Cells and Writing Data

There are several ways to write data to a cell. Replace "Text Here" with the text that you want in the cell enclosed in quotes. Assuming the cell you wish to write is B2 on Sheet1:

• Worksheets("Sheet1").Cells(2,2) = "Text here"
• Cells(2,2) = "Text here" (When Sheet1 is active)
• ActiveSheet.Cells(2,2) = "Text here" (When Sheet1 is active)
• Range("B2") = "test" (When Sheet1 is active)
• Range("B2").Select
  Selection = "test" (When Sheet1 is active)
• ActiveCell = "test" (When Sheet1 is active on cell B2)

Referencing Sheets, Cells and Variables

• ActiveSheet refers to the currently active sheet when that line of code is run. Similarly, ActiveCell refers to the current cell that was selected.
• Worksheets("Sheet1") calls a specific sheet when selecting cells or other commands. Note if a sheet with that name doesn't exist, then an error will be thrown.
• Cells (2,2) refers to the coordinates of the cell in column, row coordinates, with 1 being row A. You can use variables to determine the cell being referenced. If you want the address of the cell referenced in Letter/number notation, use Cells().Address
• Range() can be used to select a single range (such as "B2:C4"), or a series of ranges separated by commas (such as "B2, C2, D5").
  • Alternatively, just enclose the range in brackets. Ex: [B2] = "" will fill in cell B2 appropriately.
• Variables can be defined / saved using a variety of variable types: Integer, Float, Range, Date, etc.

Aesthetic Stuff

• Column widths can be set with Columns("G").ColumnWidth = 10, where G is the column you wish to have selected.
• For a range, use .Interior.Color = RGB(Red:=a, Green:=b, Blue:=C) to change cell color, where a, b, and c are values between 0 and 255 (following the RGB color scheme). To change the font color use Font.Color = ... instead. Examples: Range("F12").Interior.Color = RGB(Red:=255, Green:=0, Blue:=0) shades the background blue.

Fall 2012 in Concepts

Things change - people come and go, and in the long run, the only thing that matters is the big picture - there's a whole world to see and explore. As well as a handful of close friends to share experiences and stories with.

Fall 2012 in Concepts takes a different approach to images - it focuses less on just displaying pictures and places emphasis on various concepts - such as the programming side, covering a variety of topics set for this semester. Although originally started in 2012, this page contains info that goes well beyond that.

ZB Score Parser

This is the web program/code that results when someone decides to discontinue a "top 50" leaderboard. (UPDATE: He has returned and is now continuing top 50 leaderboards. Hopefully.)

Title: Zuma Blitz Score Parser

Description: Allows you to see a player's Zuma Blitz stats (including high score) that would normally be found under the details section of the leaderboard* and parses them into a webpage. Having a user id is enough - doesn't require that you be friends with them*. Works as of Nov 15 2011.

You will need to supply your own auth code (its different for each user) and need to be logged in to FB and must have installed Zuma Blitz to use this.

Purpose: I generally use this code to determine people's previous scores before accepting them as a friend, but can also be used to recreate a weekly high score board. Maybe even a (opt-in) world leaderboard. Hmmm...

Example: Major Mouthful (Nov 29-Dec 6) - ZumaBlitzTips (all participating players) - formatted for readability