Tenach.net

I am moving scrib‘s bugs, blueprints, and the like over to the scrib Launchpad page. There has been a higher demand on our server resources and as such, I am offloading some projects and making better use of the tools we are given by other parties (such as Launchpad). With that said, there are going to be some other changes around here. Any help would be appreciated!

Speaking of help, the Whube Developers could use some help on some of their projects! There’s room for all kind of people, be it Python or PHP programmers, documentation writers, or graphic designers. The two main projects right now are Whubetrack, an “anything tracker” written in PHP, and Syn, a package management system for Linux, written in Python.

There’s also a really awesome group, the Synthetic Intellect Institute, which are working on some great artificial intelligence and natural language projects, and I’m sure they would love to have more help!

These should be no-brainers, but sometimes we developers overlook these ‘little’ things. While this concise little list is directed toward developers, it can be applied to just about anything, including our daily lives.

1. Whatever time frame you give for a project, add a few more days/hours to it. You will need it.
2. If it is broken, just fix it. “Making it better” and “fixing it” are two different things.
3. When you are not in a position to plan a project, make sure to track everything you do, whether it be in a project tracker or a spreadsheet. You’ll thank yourself later.
4. Make sure that parts of a project are ordered in a high-to-low priority list, or you may find yourself with Lots of Gadgets but no working application.
5. Identify your time wasters (you know, like Facebook) and limit your time utilizing these while working.
6. Be sure to get some rest and relaxation! A tired brain nets poor results.
7. Ask for advice and help when you need it. Don’t beat yourself up over something when you can get help.
8. Last but not least: if it is not broken, be suspicious.

Hope you have a great Monday!

We just recently posted the initial version of a plugin we are working on for the Vanilla 2 forum software. RoleBadges shows a list of badges based on the user’s roles in a forum post. As of right now, it does not tell you what roles the images represent. That is, however, going to be in the next update.

You can see it in action over at our Scoundrels Minecraft forum.

One of the things that is being done with our project, Scrib, is building it to use CouchDB as the back-end database. The data we’ll be storing is more suited to a ‘document-style’ database rather than relational, like MySQL (here’s some pros and cons of CouchDB vs. MySQL). One of the great bonuses is that it uses a RESTful HTTP-API, which means that all of the data is accessible via HTTP requests. It also uses JSON for data transfer and storage. This makes it relatively easy to create a web-interface as the data is in a format that is not defined (like XML) and can easily be parsed.

While Scrib is utilizing it through Python, the web interface is going to be built using a mixture of HTML, JavaScript, CSS and PHP.

Utilizing PHP on Couch

For this part of the project we are going to use PHP on Couch, a PHP wrapper class to make things easy.

Most of the time CouchDB is already installed inside Linux (Debian-based distros, at least). In Ubuntu you can install it via “sudo apt-get install couchdb” (those of you who are using MacOSX or Windows, you can find respective packages here and here.)

Here’s an example of how easy it is to use CouchDB inside PHP:

After some talk with the developers of AIR, I did some of my own research into the difference between the MyISAM and InnoDB transactional storage engines found in MySQL, and found some interesting things. Contrary to my first belief, MyISAM under-performs when it comes to large-scale, simultaneous transactions (you really start seeing performance issues at around 1000 simultaneous transactions).

At first, all of the results I had were pointing to MyISAM being better, but after making InnoDB’s buffer pool larger and setting autocommit to 0 (meaning that it won’t auto commit any transactions), the results still weren’t looking too good, other than the CPU consumption was considerably lower (10-15%).

One thing I really liked was the fact that it uses row locking instead of table locking, which means that simultaneous reads and writes can be done without having to wait for the table to be unlocked. MyISAM is good for small scale websites, as InnoDB performs slower if there are fewer than 100 or so simultaneous connections and if the data is small (below ~10MB per transaction).

For now I think I will stick to MyISAM for my everyday coding, but I already know a few sites that could benefit from an engine switch…