Error Handling

It can now handle internal issues with network communication to the data source and incorrect JSON formatting of retrieved data. Bitcoin Helper 0.11 also checks to ensure the requested ISO 4217 currency code, for conversion to Bitcoin, is supported.

Certain functions in Bitcoin Helper now return a negative integer in the case that an error occurs. Details regarding these error codes can be found in the source code comments of bitcoin_helper.php. The relevant section of commenting is quoted below for convenience.

/* Information about error codes

Certain functions within Bitcoin Helper (0.11 onwards) will return
numeric error codes in the case of unexpected error or failure.

You should make sure to check the returned value for error codes
(intergers less than zero) in your code. The following reference
shows the error numbers and an explanation.

* -1 = Network error retrieving data from bitcoincharts.com
* -2 = Error decoding JSON data retrieved from bitcoincharts.com
* -3 = Currency code not supported
* -4 = Could not write to cache file – check permissions!
*/

File-based Caching

Bitcoin Helper 0.1 would cache the JSON containing currency exchange rates to a file if possible. This caching is now a requirement as of Bitcoin Helper 0.11.

Bitcoin Helper will attempt to write a file named ‘bitcoin_weighted_prices.json’. If this file is not writeable, you will receive error code -4.

If you receive this error, you will need to alter the permissions of the directory to allow this file to be created. Once created, you can revert the directory permissions if you desire and make only the individual ‘bitcoin_weighted_prices.json’ file writeable.

Download Bitcoin Helper 0.11

To download Bitcoin Helper 0.11 with improved error handling, please go to the Bitcoin Helper project page.

Bitcoin is a new currency which has no physical form, but can be considered Internet cash. If you want more information on Bitcoin in general, take a look at the We Use Coins website, which has a great introductory video and articles/links to other useful Bitcoin resources.

Bitcoin Helper 0.1 Released

As part of my interest in Bitcoin, I’ve decided to start a mini-project in the form of Bitcoin Helper, a PHP class which will contain multiple methods to aid web site/application developers in integrating Bitcoin related functionality into their systems. The first function, which comes in Bitcoin Helper 0.1, is a really easy to use converter that can convert non Bitcoin currencies into the equivalent Bitcoin value and return the result.

To see how simple it is to use, see the following code snippet.

include "bitcoin_helper.php";
$bh = new bitcoin_helper;
echo $bh->convert_to_btc("GBP", 10);

This will convert £10 (Great British Pounds) into Bitcoin and echo out the result. The following works for USD and Euros as well.

echo $bh->convert_to_btc("USD", 10);
echo $bh->convert_to_btc("EUR", 10);

The trade data for several other currencies is provided from the external source (see the Bitcoin Charts website). If your currency is listed there, entering its ISO 4217 currency code as the first parameter of the convert_to_btc function should allow you to convert any value of that currency into Bitcoin.

Please note that this is the first release of Bitcoin Helper, so I can not guarantee it is bug free. More checks, validation, improvements and new features will be added in the future versions. Feel free to leave a comment with any suggestions.

I hope this very basic Bitcoin Helper release can assist web developers with some simple Bitcoin conversion in their sites.

Download Bitcoin Helper 0.1

To download this first version of Bitcoin Helper (0.1), please visit the Bitcoin Helper project page.

A short while ago, I read this from Alex Yumashev’s Jitbit blog:

I just overheard this conversation between two developers at a co-working site:

“I plan [on] creating a prototype for my new XXXX application, whatcha think it should be – a web-app, or a desktop app?”

The answer was:

“90% of your users are idiots who won’t be able to tell the difference”

I think I just found my answer to the ultimate question of life universe and everything and it’s not “42″.

It’s “90% of your users are idiots”.

Now thats a questionable term to describe your customers. I don’t think 90% of my users are idiots. But. That’s the way to think of your users when making design decisions and building your interface.

Jitbit Blog

And he’s very right.

Thinking about some of the largest and most successful software developments, this rule applies – not that 90% of the users of these systems are idiots, but more that they are designed to accommodative for 90% of their users being idiots .

Think about the operating systems environment, in which Mac OS X and the Windows series of operating systems are by far the most popular on the desktop. Both of these systems are developed to heavily guide the user through any process or task that he or she wishes to complete, metaphorically holding the users hand throughout each step.

The mobile market is the same. Up until very recently, iOS (the Apple operating system powering the iPad and iPhone) was very far in the lead in terms of sales and end-user popularity. Android has only recently, in the past few months starting competing well with iOS. iOS is simple. In my opinion, too simple, but people like it and use it, on a huge scale. 90% of users are idiots. As Android has got more and more user-friendly, it has increased in popularity amongst end-users, along with the ever increasing push from non-Apple phone and tablet manufacturers to use Android.

Both user interface and structural application decisions can often benefit from thinking that 90% of your users are idiots.

1. Should I implement feature X in either A or B way? Whichever is easier for those 90%.
2. Should I design the user interface to promote feature A or B most promotion? Whichever is most appropriate for those 90%.
3. Do I design this icon that triggers feature X to represent concept A or concept B? Whichever will make the most sense to those 90% of users.
4. Should I document this little used and/or somewhat obvious feature? Of course – 90% of your users are idiots.

The experts among us do not necessary need or want to be guided though every step of a process with our hands held all the time. Some of us just want to dig into plain text config files and command line interfaces. The developers and the computing enthusiasts, we’re the remaining 10%.

One of the best ways to implement the database storage of PHP session data is via the overriding session handlers built in to PHP. PHP has functions built in to allow you to override the default file based session handlers.

These functions all use PHP’s normal ways of handling session persistence between the client and the server (by default, via the use of a session ID cookie).

In other words, it utilises the same PHPSESSID cookie that the default file based session storage uses. When using functions that override the session handlers, the first parameter for several of these function is the session id. Upon overriding the functions, PHP will automatically pass the session ID (pulled from the PHPSESSID cookie) to these functions.

The code linked to below can be ‘required’ (require “session_start.php”) as a drop in replacement for the default PHP session_start() function. This utilises database access to store and retrieve session information. Note that due to the very early point in which PHP processes session handler overrides, objects are not available for use, hence the use of old style ‘mysql’ instead of OO based ‘mysqli’ (if you find a way around this, I’d be very interested in hearing about it).

Download ‘session_start.php’ for database storage of session data

Required Table Structure SQL

In terms of performance, there is limited degradation to using database stored sessions with most small to mid range sites, based on my experience and observation. However, larger sites may possiblynotice degradation. In such circumstances, this would likely be related to the MySQL database server load and/or high levels of IO on the MySQL server. Issues of database server load can be mitigated via one or more of the following:

• Separation of the site database and the session storage database (seperating each to their own server if necessary)
• File based caching of session information on the web server system (using standard PHP file reading/writing functions, ensuring that the file cache is updated whenever there are changes to the session information in the database store)
• In memory caching (similar to file based caching, but utilising a key to value storage engine which runs in RAM, providing very fast (atomic) access to data) – using a system such as memcached - http://memcached.org/

For building reasonable size websites in which portability is important, the need to load balance is highly probably in the future and where development time permits, I’d  personal recommend database storage for session information, due to the higher level of flexibility this set-up offers.

I hope this information helps anyone looking to make a PHP powered site just that little bit more portable by placing their users’ session data in a database.

In the vast majority of today’s websites, if a program is required to pick out a particular part of a HTML page, such as the main article, the sidebar or the top navigation, it would have to be programmed to do so on a per website and web page basis. This is because every website structures its HTML differently, unless based on an underlying package with a consistent HTML foot print.

Most current websites therefore use a variety of <p>, <div> and <span> tags to surround their content. These tags define style and do not obviously determine whether the contained content is part of the website’s navigation system or whether it is the main article or focus of the web page. The new HTML 5 tags aim to change this by explicitly defining content.

Defining content with specific HTML 5 tags will make websites easier to parse by computer programs. This could benefit accessibility readers for the blind and allow content aggregating systems and ‘mash-up’ websites to easily parse, link to and cite your articles. Content aggregation and automation of web page content retrieval is quite fundamental to some of the newer Web 2.0 sites and social networks. Good examples being Facebook’s automatic retrieval of web page information when a link is entered into a status update, or Reddit’s automatic thumbnail generation based on images found within the linked web page.

Here is a listed on related HTML content tags, as available from the W3C Schools website.

• <article> – Defines a main article on a page. Can include cite (citation) and pubdate (publishing date) attributes.
• <details> – States content details for a specific section. Can include an open attribute defining whether or not the details within are visible to the end-user.
• <figcaption> – States the caption for a figure as defined by the figure tag.
• <figure> – Usually used to group a set of elements.
• <footer> – Footer layout element. This is used to contain the footer content of the page, usually contains the website name, author and copyright information.
• <header> – Header layout element. This tag is designed to contain the top header of a document, usually showing the website logo, page and/or company title and subtitle.
• <hgroup> – A tag used to group together heading tags such as <h1>, <h2>, <h3> and so on.
• <keygen> – A key generation tag which defines a generated (encryption) key that can be associated with a HTML form.
• <meter> – The <meter> tag contains content which is deemed to be a measurement of some sort.
• <nav> – The <nav> tags stands for navigation and is designed to surround navigation links, such as those present in a sidebar bar or navigational header/footer.
• <summary> – The <summary> tag defines the title of a <details> element.
• <time> – This tags contains content which is a statement or measurement of time and/or date/time.

Unfortunately, it is likely that HTML 5 content tags with not be adopted completely for quite some time and there will likely continued use of existing HTML mark up and related styling of <div> and <span> tags for quite some time.

This makes systems using a model view controller architecture much simpler to maintain, as locating the code relevant to specific logic is significantly easier. Additionally, it makes expansion of systems much less complex, as it avoids the ‘feature cascade’ effect in which the addition of a single feature will result in a knock on or butterfly effect throughout the entire system.

The parts of a model view controller system are referred to as models, views and controllers, which makes perfect sense. The definition of these system parts is also quite intuitive.

• Views – Views are entirely for the presentation part of your application. It contains no brains, no logic, no intelligence to the extent permissible by the programming language used. A view is merely the appearance of your application and nothing else.
• Controllers – A controller handles feedback from the user and logic specific to the application. A controllers job is to receive input from a user, via controls found on the user interface of a view, to process it, communicating with a model if necessary, and then to send output to the user, usually by populating a view with relevant content.
• Models – Models perform business logic. Business logic, in this case, refers to items that are fundamental to the overall system design. For example, if a library application was constructed, the logic which ensured a library card owner only rented up to 5 books at a time, would be part of a model. Again, as part of the business logic, models also tend to control access to application storage, such as database(s), performing CRUD (creation, updating and deletion) tasks on the stored data.

I hope this helps explain the basics of the model view controller software architecture.

If you have any improvements or additions to these definitions or just want to discuss software architectures in general, feel free to use the comments section below.