While there is a lot of history before this point, let’s start at mainframes and terminals. See a pattern here?

• Remote – Terminal / Mainframe
  During this phase of our history one could sit down at a dumb terminal that had a direct connection to the mainframe. This would provide remote access to the functionality on the server but wouldn’t provide much other functionality.
• Local – Thick client apps
  Next came thick client apps. That is, applications that are physically installed on a computer. This typically moved a lot of the processing off the central system and onto a stand alone computer. A good example of this is word processing.
• Remote/Local – Distributed thick client apps
  Once thick clients were widespread the software industry quickly realized they had a problem. They needed easy ways to update their thick client applications but also needed to be able to gather and aggregate data across all of the installations. The resulting evolution was a set of applications that could communicate with a central server as well as install updates as necessary, all without needing a technician physically present.
• Remote – Web based apps
  The software industry quickly realized that the bulk of the functionality that they were installing on people’s computers could easily be handled via the internet, given the advance of software and networking technologies. Thus, the web based app was born. These apps provide 90% of what most users need without the overhead of distributing, installing, and supporting thick client software. Note, however that specific app needs still have to be addressed with this clients, even in this evolution, 3D rendering being a good example.
• Local – Thick client mobile apps
  As the mobile world started to mature we found that the hardware in our mobile devices was becoming much more powerful and capable of handling apps. At this time the browser capabilities of these devices as well as the ability to have fast mobile networking was sufficiently infantile that once again we found ourselves utilizing thick client apps as the best way to deliver functionality.
• Remote/Local – Distributed thick client mobile apps
  Once again, technology advances delivered us better mobile browsers and a newfound ability to handle much faster networking on mobile devices, giving birth to the distributed thick client apps for mobile devices. These apps, in many regards, follow the same basic principles as the distributed thick clients of the PC era. They are installed but can update themselves and communicate with a remote server or servers.
• Remote – Mobile responsive apps
  This phase of our evolution is unfolding now and is really just starting to gain traction. Over the next year this will become the de facto way that the majority of companies get their data into a mobile device. The responsive layouts concept is a way of designing a web site/application in a such a way that it understands what kind of device (PC, phone, tablet, etc.) it is being displayed on and applies the correct styling for that type device. Bank of America has a pretty good example of this. If you visit their mobile site you are seeing the same basic content you would on their primary site, however it has been styled so that it works well and is easy to use on your mobile device.

Predicting what comes next in this evolution isn’t exact but also isn’t particularly difficult. We’ll likely see bridges to cross some of the major gaps that currently tie us to mobile devices, such as:

• Browser support for mobile features
  Mobile browsers will likely continue to begin supporting, or at least provide an API for supporting, multiple features that are device specific, such as GPS or the accelerometer. Likewise, mobile operating systems will continue to evolve in such a way that allows the browser to more easily interact with the mobile system.
• Generic push notification capabilities
  One of the major limitations today that cause companies to gravitate towards thick client mobile apps are push notifications. If I want to be able to notify a user of a particular event the only way to do so today is to utilize the push API for a particular device. My hope is that this functionality will become standardized in such a way that notifications can be sent to a central location (albeit, possibly different device dependent locations) that knows how to notify the device in a manner suitable to that device.For example, my web application may trigger an event that then notifies the Apple servers of the event and provides a unique key that was authorized by and identifies the device. The Apple servers would then know how to send the notification to that device based on the unique id. Users would be able to easily control who does and doesn’t have access to push to them in the same manner they do today, only the system would be distributed.

Until these changes take place there will always be a need for a thick client mobile app in certain situations. Just don’t write a custom thick client app for a mobile device unless you actually need the features that are offered by the mobile device you are writing for. If you just want an app for the sake of having an app, spend your money having a good designer build a mobile responsive layout for your site. However, if you actually need things like GPS, accelerometer, notifications, or other device specific features, you really don’t have much choice, in present day, but to write a thick client mobile app. In this situation you should still follow the web based paradigm as much as possible and keep as much content web based as you can.

Sorry for the inconvenience.

[Finished...]

Click The Great Trashy (yes, that’s a Fraggle Rock reference…) for the full story.

He has been in the hospital ever since.

The Post and Courier is keeping up with his progress so I’ll not go into those details. Here is a link to one:
http://www.postandcourier.com/news/2011/dec/08/snakebite-victim-improves/

He has had over 40 vials of anti-venom throughout this ordeal, each of which can cost upwards of $10,000. He has been hospitalized in intensive care for nearly a month now and has been on breathing support.

Needless to say, the medical costs associated with this can be huge. I’d ask that if you can give anything, even if it is just a couple bucks, you visit the button below and do so. The button below is a PayPal account set up in Zach’s name. You don’t have to have a PayPal account and can use any major credit card for payment.

Thank you in advance for your support.

Let’s look at an example. We’ll use nice, round numbers to keep things easy to digest and assume the chosen income tax rate is 10%. The following is the breakdown for what you’d expect to pay at different income levels:

Figure 1: Basic flat tax example

Pretty simple and fair, right? Maybe, but it isn’t quite that simple.

Flat taxes are based on standard income. In general, investment income is often taxed at lower rates than regular income, provided it is considered to be a qualified dividend. A qualified dividend, simplified, is a payout from an investment that is considered to be a long term investment. This lower rate varies but is typically lower than the income tax rate and is one of the reasons why some extremely wealthy Americans are able to pay lower tax rates than their less wealthy counterparts.

Most of the wealthiest Americans are company owners and heavy investors, which gives them the opportunity to choose how to route their income. For example, as a business owner, I can choose to pay myself a small salary but pay very high annual dividends, thus diverting the majority of my income to qualified dividends, which are generally taxed at a lower rate.

How’s this work? Let’s use another very simple example to illustrate. Let’s assume now that qualified dividends are taxed at a 5% interest rate and all other aspects of the prior example remain true, with the exception that the top two earners in our scenario have shifted where their revenue derives from in order to minimize taxes owed:

Figure 2: Example using dividend income.

It is important to note that paying a lower tax rate doesn’t mean paying less taxes. As we see in the example above, wealthier individuals still pay more in gross taxes, however their proportion of income paid in taxes is a much lower percentage than their less wealthy counterparts, which is what Warren Buffet pointed out recently.

In short, the tax code is very complex. By diverting funds through different investment and holding strategies, accountants are able to reduce, and sometimes eliminate, taxes all together.

A flat tax could work. However, what most flat tax plans fail to account for is where the majority of income comes from. If 90% of the revenue individuals receive come from dividends, it would make sense to tax that revenue as income, not as investment payouts. But still, it isn’t that simple – for example, how should retirees that have no income except from dividends be taxed? Would it make a difference if these retirees have annual dividend payouts of only $30,000? What if their annual payout was $3,000,000? It isn’t cut and dry.

Regardless of your political orientation, don’t take any political plans at face value. When you hear a 30 second clip on the news or read 2 paragraphs you don’t have enough information to fully understand a complex and well planned change to a very complex institution.

Don’t support policies blindly. Research and understand what you are supporting.

So my wife started looking around and came across http://ana-white.com/, which had plans for a pretty simple play fridge. The one she had was a little bit too small and didn’t quite match what we have already, but seeing the plans made me realize how easy it was to put together a simple set of plans that did match what we have.

So I drew up some plans, which are available from the link below. The fridge turned out great. It matches the existing set in size, color, and style. The kids love it. The total cost was around $50 but would have been even less had I not gone to a home store for all my lumber.

Here are some pics (click for full sized image):

You can download the step by step plans here:
Play Fridge Plans

If you found these plans useful, please consider making a small donation. The ad revenue for this site doesn’t quite cover rent.

So I decided to create a simple, purely web based drawing tool. This works in all browsers and even works on my iPad (although I have to click each square to form the drawing on the iPad since dragging simply moves the screen). The canvas, with a drawing, is shown in Figure 1.

It uses some simple JavaScript and CSS to achieve the effect. The grid lines, border, and cell size are all controlled by CSS. Just click or click and drag to draw. Do the same while holding down the SHIFT key to erase (draw in alternate color). I chose to use the SHIFT key combination for color 2 to avoid conflict with context menus when right clicking and OS specific uses for ALT and CTRL.

Figure 1: Picture of a drawing done on “Canvas” (demo link below).

Everything is encapsulated inside the Canvas object, so it is really easy to use. All you need is a DIV, a little bit of CSS, and the couple lines of JavaScript below.

Here’s how to use it:

// Creates the canvas - just make sure you have a DIV with an id of "drawingArea"
// The last parameter of false allows editing - set to true for read only
// Note that these are squares - actual square size is set via CSS
var myCanvas = new Canvas("drawingArea", 60, 40, false);

// This will change the drawing colors
myCanvas.setFillColor("#CCCCCC"); // #000 by default
myCanvas.setEraseColor("#555555"); // #FFF by default

// This will resize the canvas, preserving what portions of the drawing it can
myCanvas.resize(100, 10); // 100 wide by 10 high

// This will save the contents of the canvas down to a JSON string
var myData = myCanvas.save();

// This will load a drawing from a JSON string
myCanvas.load(myData);

You can view a working demo here.

You can find the JS file here:
http://www.mcdonaldland.info/files/canvas/canvas.js

Note that you’ll also need the JSON2 JS file as well:
http://www.mcdonaldland.info/files/canvas/json2.js

An improvement idea:
When mouse moves fast, lines have gaps in them. It would be pretty easy to write an algorithm that figures out empty squares between two points and fills them in. Alternatively, it wouldn’t be too difficult to handle this without tables by tracking the mouse location within the DIV then drawing points/lines.

Feel free to use this as you see fit. I just ask that you:

1. Leave the copyright information at the top of the JS file in place.
2. Don’t sell the code or any product that has this code as the core feature without my consent.

Enjoy!

I have a situation where I want to send an event to an instance of a JavaScript object. I could get it to go to the object itself, but was having trouble getting it to apply to only a specific instance of the object.

The answer was surprisingly simple – just wrap the pointer to your event handler function in an anonymous function. Doing this gives the anonymous function (closure) access to the variables currently in scope, which means that I have access to my object instance now.

The code is below. The commented out event listener add lines were the original attempt that would result in “undefined” being printed to the screen instead of my instance variable value. The uncommented version correctly calls my instance, which prints “test” to the debug area of the screen each time it is clicked.

// The object to handle the event...
function TestListenerObj(txt) {
    this.eventText = txt;
    this.handleEvent = function() {
        var debug = document.getElementById("debug");
        debug.innerHTML = debug.innerHTML + this.eventText + "<br/>";
        return false;
    }
}

// Sets up the event handler
function init() {
    var link = document.getElementById("test_link");
    var obj = new TestListenerObj("test");

    if (link.addEventListener) {
        // link.addEventListener("click", obj.handleEvent, false); // Calls "class" level handleEvent()
        link.addEventListener("click", function() { obj.handleEvent(); }, false); // Calls instance level handleEvent()
    } else {
        // link.attachEvent("onclick", obj.handleEvent ); // Calls "class" level handleEvent()
        link.attachEvent("onclick", function() { obj.handleEvent(); }); // Calls instance level handleEvent()
    }
}

For a working example go here. For complete source visit this link and view source. Just click the “Test” link on the example to see the event be handled by the object, which in this case just prints to the debug area.

I have a need to download a ton of images from a site (I got permission first…) but it is going to take forever to do by hand. Even though there are tons of tools out there for image crawling I figured this would be a great exercise to brush up on some skills and delve further into a language I am still fairly new to, Ruby. This allows me to use basic language constructs, network IO, and file IO, all while getting all the images I need in a fast manner.

As I have mentioned a few times on this blog, I am still new to Ruby so any advice for how to make this code cleaner is appreciated.

You can download the file here: http://www.mcdonaldland.info/files/crawler/crawl.rb

Here is the source:

require 'net/http'
require 'uri'

class Crawler

  # This is the domain or domain and path we are going
  # to crawl. This will be the starting point for our
  # efforts but will also be used in conjunction with
  # the allow_leave_site flag to determine whether the
  # page can be crawled or not.
  attr_accessor :domain

  # This flag determines whether the crawler will be
  # allowed to leave the root domain or not.
  attr_accessor :allow_leave_site

  # This is the path where all images will be saved.
  attr_accessor :save_path

  # This is a list of extensions to skip over while
  # crawling through links on the site.
  attr_accessor : omit_extensions # Remove space between : and o - WordPress tries to make this a smiley if I leave them together.

  # This keeps track of all the pages we have visited
  # so we don't visit them more than once.
  attr_accessor :visited_pages

  # This keeps track of all the images we have downloaded
  # so we don't download them more than once.
  attr_accessor :downloaded_images

  def begin_crawl
    # Check to see if the save path ends with a slash. If so, remove it.
    remove_save_path_end_slash

    if domain.nil? || domain.length < 4 || domain[0, 4] != "http"
      @domain = "http://#{domain}"
    end

    crawl(domain)
  end

  private

  def remove_save_path_end_slash        
    sp = save_path[save_path.length - 1, 1]

    if sp == "/" || sp == "\\"
      save_path.chop!
    end
  end

  def initialize
    @domain = ""
    @allow_leave_site = false
    @save_path = ""
    @omit_extensions = []
    @visited_pages = []
    @downloaded_images = []
  end

  def crawl(url = nil)

    # If the URL is empty or nil we can move on.
    return if url.nil? || url.empty?

    # If the allow_leave_site flag is set to false we
    # want to make sure that the URL we are about to
    # crawl is within the domain.
    return if !allow_leave_site && (url.length < domain.length || url[0, domain.length] != domain)

    # Check to see if we have crawled this page already.
    # If so, move on.
    return if visited_pages.include? url

    puts "Fetching page: #{url}"

    # Go get the page and note it so we don't visit it again.
    res = fetch_page(url)
    visited_pages << url

    # If the response is nil then we cannot continue. Move on.
    return if res.nil?

    # Some links will be relative so we need to grab the
    # document root.
    root = parse_page_root(url)

    # Parse the image and anchor tags out of the result.
    images, links = parse_page(res.body)

    # Process the images and links accordingly.
    handle_images(root, images)
    handle_links(root, links)
  end

  def parse_page_root(url)
    end_slash = url.rindex("/")
    if end_slash > 8
      url[0, url.rindex("/")] + "/"
    else
      url + "/"
    end
  end

  def discern_absolute_url(root, url)
    # If we don't have an absolute path already, let's make one.            
    if !root.nil? && url[0,4] != "http"

      # If the URL begins with a slash then it is domain
      # relative so we want to append it to the domain.
      # Otherwise it is document relative so we want to
      # append it to the current directory.
      if url[0, 1] == "/"
        url = domain + url
      else
        url = root + url
      end
    end    

    while !url.index("//").nil?
      url.gsub!("//", "/")
    end

    # Our little exercise will have replaced the two slashes
    # after http: so we want to add them back.
    url.gsub!("http:/", "http://")

    url
  end

  def handle_images(root, images)
    if !images.nil?
      images.each {|i|

        # Make sure all single quotes are replaced with double quotes.
        # Since we aren't rendering javascript we don't really care
        # if this breaks something.
        i.gsub!("'", "\"")        

        # Grab everything between src=" and ".
        src = i.scan(/src=[\"\']([^\"\']+)/i)
        if !src.nil?
          src = src[0]
          if !src.nil?
            src = src[0]
          end
        end

        # If the src is empty move on.
        next if src.nil? || src.empty?

        # We want all URLs we follow to be absolute.
        src = discern_absolute_url(root, src)

        save_image(src)
      }
   end
  end

  def save_image(url)
    # Check to see if we have saved this image already.
    # If so, move on.
    return if downloaded_images.include? url        

    # Save this file name down so that we don't download
    # it again in the future.
    downloaded_images << url

    # Parse the image name out of the url. We'll use that
    # name to save it down.
    file_name = parse_file_name(url)

    while File.exist?(save_path + "/" + file_name)
      file_name = "_" + file_name
    end

    # Get the response and data from the web for this image.
    response = fetch_page(url)

    # If the response is not nil, save the contents down to
    # an image.
    if !response.nil?
      puts "Saving image: #{url}"    

      File.open(save_path + "/" + file_name, "wb+") do |f|
        f << response.body
      end
    end
  end

  def parse_file_name(url)
    # Find the position of the last slash. Everything after
    # it is our file name.
    spos = url.rindex("/")    
    url[spos + 1, url.length - 1]
  end

  def handle_links(root, links)
    if !links.nil?
      links.each {|l|    

        # Make sure all single quotes are replaced with double quotes.
        # Since we aren't rendering javascript we don't really care
        # if this breaks something.
        l.gsub!("'", "\"")

        # Grab everything between href=" and ".
        href = l.scan(/(\href+)="([^"\\]*(\\.[^"\\]*)*)"/i)
        if !href.nil?
          href = href[0]
          if !href.nil?
            href = href[1]
          end
        end

        # We don't want to follow mailto or empty links
        next if href.nil? || href.empty? || (href.length > 6 && href[0,6] == "mailto")

        # We want all URLs we follow to be absolute.
        href = discern_absolute_url(root, href)

        # Down the rabbit hole we go...
        crawl(href)
      }
    end
  end

  def parse_page(html)    
    images = html.scan(/<img [^>]*>/i)
    links = html.scan(/<a [^>]*>/i)

    return [ images, links ]
  end

  def fetch_page(url, limit = 10)
    # Make sure we are supposed to fetch this type of resource.
    return if should_omit_extension(url)

    # You should choose better exception.
    raise ArgumentError, 'HTTP redirect too deep' if limit == 0

    begin
      response = Net::HTTP.get_response(URI.parse(url))
    rescue
      # The URL was not valid - just log it can keep moving
      puts "INVALID URL: #{url}"
    end

    case response
      when Net::HTTPSuccess     then response
      when Net::HTTPRedirection then fetch_page(response['location'], limit - 1)
      else
        # We don't want to throw errors if we get a response
        # we are not expecting so we will just keep going.
        nil
    end
  end

  def should_omit_extension(url)
    # Get the index of the last slash.
    spos = url.rindex("/")

    # Get the index of the last dot.
    dpos = url.rindex(".")

    # If there is no dot in the string this will be nil, so we
    # need to set this to 0 so that the next line will realize
    # that there is no extension and can continue.
    if dpos.nil?
      dpos = 0
    end

    # If the last dot is before the last slash, we don't have
    # an extension and can return.
    return false if spos > dpos

    # Grab the extension.
    ext = url[dpos + 1, url.length - 1]

    # The return value is whether or not the extension we
    # have for this URL is in the omit list or not.
    omit_extensions.include? ext

  end

end

# TODO: Update each comparison to be a hash comparison (possibly in a hash?) in order
# to speed up comparisons. Research to see if this will even make a difference in Ruby.

crawler = Crawler.new
crawler.save_path = "C:\SavePath"
crawler.omit_extensions = [ "doc", "pdf", "xls", "rtf", "docx", "xlsx", "ppt",
                          "pptx", "avi", "wmv", "wma", "mp3", "mp4", "pps", "swf" ]
crawler.domain = "http://www.yoursite.com/"
crawler.allow_leave_site = false
crawler.begin_crawl

# Bugs fixed:
# 1. Added error handling around call to HTTP.get_response in order to handle timeouts and other errors
#
# 2. Added check upon initialization to remove the trailing slash on the save path, if it exists.