My views on software, programming, Linux, the Internet, government, taxation, working, and life.

Saturday, July 15, 2006

Get Swiftfox on Ubuntu and Speed Up Your Web Browsing Tremendously!

Man, I have great news.

After reading about this in a forum, I installed Swiftfox on Ubuntu to replace Firefox (and still leave the old Firefox icon). I think you have to be on the 686 kernel, though, to run it -- not certain of that.

Anyway, to get it, you go to:

(Info is here: )

When you download and expand the file to a folder, it's ready to go -- no compilation necessary. You just launch swiftfox. I found that after two runs of it, it "stole" a copy of all my old Firefox bookmarks and plugins -- isn't that cute?

I found I could still run the old Firefox if I wanted, as well.

I then changed my icon to point to Swiftfox.


I found what seems like a 2x speed improvement in using Swiftfox rather than Firefox!!! Woo hoo!!! It makes my Internet zippy fast. I can now honestly say that my web browsing experience is way, way faster than Internet Explorer on this same hardware.

My website project that I've been working on now races by me on the screen. Click, bam. Click, bam. Unbelievable!


BTW, Ubuntu, by default, uses a 386 kernel which is fairly slow. It does this to fit the largest variety of processor types. If you want to get the 686 kernel for Ubuntu to speed it up, do this:

  1. # sudo apt-get install linux-686

  2. Reboot into the new kernel.

  3. Open Synaptic Package Manager and search on 386. If it has the word "kernel" on the line, rightclick and choose Remove All. When prompted for other stuff immediately in the GUI when doing this selection, choose Yes. When you click Apply, it first prompts you what it's going to do. Ensure it only lists kernel stuff in there, not removal of Ubuntu desktop, GNOME, etc. Then, click the button to apply the changes. BUT WAIT!!! Click "Show Terminal" and you'll see you might be prompted something. Click "n" for No. Now reboot when done.

  4. Repeat step 3 until you no longer have kernel stuff, rebooting as necessary, repeating step 3 as necessary, until all 386 stuff is gone. By removing all 386 stuff, you won't get prompted for Kernel 386 package release stuff and will only be prompted in the future for Kernel 686 package releases.

Ways To Improve Your PHP

I've collected some ways to improve your PHP web application development over the years.

Turn off magic quotes. These are very bad because it can mangle strings and make it hard to parse stuff. You can google for what I'm talking about.

Use a template page. Usually my template page, from the top down, consists of a graphical banner, a ridge, a section title to define where we are in the page, another ridge, a thin spacer line, a breadcrumb set of links to define what page we're on and where we came from, along with "Home", and then a band where on the left I have the username and full name of the logged in user, and on the right on that same band I have the series of menus. I follow this with another thin spacer line. From there on out, it's a blank white page (because these print nicely to a printer) that I can customize to do anything I want. But behind the scenes in the server-side code, I start with PHP tags and then follow it with the HTML. Unfortunately, however, this got a bit messy because I was interspersing HTML and PHP, creating a confusing mess, so now I do all my HTML via functions inside my PHP code section and have no HTML section anymore. Also, I even go as far as building a template of sections in the PHP (using comments) that define what I will do in the page. I've done so many things in PHP now that I've got a standard way of doing things, such as doing includes at the top, followed by initialization of vars with initial values, then read any form vars, or query parameter vars from the URL, then do some business logic, then read from the database, etc. You get the idea. Do what works best for you.

Worship Cascading Style Sheets. Do not use font tags in HTML and instead put everything through CSS class tags. Think about having the ability to easily reskin the app -- that's cool! The big test is that without this CSS file, your page should be white with no banner, no images, and only black text. You need to run this test on every page and if you're not to this level, then switch things out to use more CSS so that you are.

Define a variety of 3 color themes on white pages and then find colors that are in the same hue but blend well with one of these 3 colors. In your CSS, use this theme consistently through your pages to keep users feeling comfortable.

Use DIVs, combined with CSS, to format the page instead of doing it with tables, EXCEPT in the case where tables make sense like with columnar grid data like what you'd see with helpdesk tickets or inventory records. Of course, using DIVs when you've used TABLE tags for so long can be frustrating and a big learning curve. Spend about a week trying to overcome that, using examples from the web, and then from there on out you should be okay.

HTML can get in your way and it gets confusing to see PHP, then HTML, then PHP again. It's almost impossible to improve and follow. Instead, create a class page with an object called "page" and then call methods (functions) off of that object so that it draws the HTML for you. That way, everything on the page becomes a kind of "gadget". Then, it's easier to compose pages as well as make them look similar.

Consolidate all your database calls into one single class file page that you include as you need. No single page should use database API specific calls except this page. In this manner, you can now swap out this page with another page and talk to a completely different database. That's cool! I also don't include SQL strings in my pages if I can help it. Instead, I put all my SQL strings into a single settings page.

A .conf file is like a Windows INI file. You set settings in it that the application can read and use, and someone who hosts the website or administers it can edit this to change the application functionality a little. Well, I wouldn't bother much with learning the PHP to read these files, nor bother with composing it in this way. Instead, just make a class file with all the settings inside set by prefixing them with $this->, such as "$this->CURRENCY = 'USD$';". End everything with a semicolon. Then, include this page with the page that needs to read it by using require_once(). You'll find that by using this technique, the speed of the application in reading these files will improve slightly. Also, because this is a PHP page, hackers can't easily see these settings like they could a .conf file in the same directory as the web app.

In my settings PHP page (my .conf file replacement), I use SQL strings that has little caret symbols inside "^" where I mean to place some value before it gets sent to the database. I have a short little routine that pushes values into these strings where these symbols are.

Never take a user-supplied password and send it to the database. Instead, read the password from the database for the given username and compare it with the password that was typed. Otherwise, someone could use a technique called SQL Injection to login to your application when they should not. Also, to do things better, create shadows of your passwords with your own encryption routine and store the shadow in the database. Then, when the user submits their password, you could create a shadow on the fly for it and compare it with the shadow stored in the database. By using this means, you have more protection against hacking.

Create a separate folder for your images. You'll make the application programming less confusing. Also, use them sparingly. You'll be amazed how clean an app can still look if you use CSS and sections of color more often then you use images. A few well-planned images are what I recommend, instead. Besides, it improves application performance. Note also that you can use CSS to simulate a kind of gradient or jazz up your banner rather than including images. You can also use CSS and Javascript to make DIVs into buttons.

If your application has a common functionality that people will most naturally want to do on a given page, then make that functionality into a big button to improve ease of use. If you have a case where you would end up filling the page with big buttons, then sort by functionality and consider using either 1, 2, or 3 buttons from that list, instead.

Properly indent your code!

Use line spaces between sections of code that exemplify a certain concept, or which use a certain kind of control structure like if {}, for {}, etc.

Properly comment your code -- not too much, not too little.

For my variables, I use this convention:

  • rsA = Rows A

  • rwA = Row A

  • hA = Handle/Pointer A

  • nA = Numerical A

  • sA = String A

  • dA = Date A

  • bA = Boolean A

  • cx = Char c1, c2, c3, etc.

  • oA = Object A

  • uA = Unknown data A

  • xA = byref (&) of A

  • a + x + A = array of "x" for A

  • i, j, k, x, y, z (alone) = loopvars

  • g + x + A = Global A of var type "x". To sort of indicate a page "global" in special rare cases where necessary.

I really hate recursive pages and use them sparingly when they make sense. Recursive pages, where you submit form information on a page back to itself, can create some confusing code. Instead, I prefer to create another page. However, if I have login page, I don't call it "check_login" as the page it submits to. Instead, I use "l1" and "l2", where "l1" is the login page and "l2" is the page it submits to. This helps programmers understand my logic a little better.

I like to build apps with a small footprint. I don't require a lot of dependencies if I can, and I make it easy to deploy my apps by simply putting them on the webserver in a virtual directory, followed by hitting the URL. The website should automatically detect that it has not been configured and provide a way for me to configure it by showing me either a "wizard" set of pages of sorts, or just pages with screenshots and instructions of what I should do manually to configure the application and get it ready for use. So many applications I download from the web have huge, frustrating footprints and steep learning curves before you can use them. This is somewhat aggravating.

This is also why I don't use Flash, Java applets, a bunch of Java, and excessive Javascript (as well as too much AJAX) with my site -- it raises the dependencies.

I like to store a backup database schema for those zero day cases where you need to recover the schema again and recreate the database.

I'm not a big fan of OOP. I use it sparingly where it makes sense. Instead, I use OOP to classify like functions together as methods, and then it's like a toolbox I can include on each page. I don't try to make everything an object. For instance, some developers I know would practically make the lint of their customer's toes into an object if you let them. And why do I do this? Because I want to get work done, not be stuck in meetings all the time.

PHP code usually compresses rather nicely if you don't stick the database into the same directory. Therefore, since I develop on Linux, I use a cron schedule and I schedule backups every 4 hours to occur to copy my directory and back it up to a large USB hard drive. In this backup script, it compresses a copy of the folder as well as deletes any old compressed backups that are older than about 6 months. Routinely I also use a USB memory stick to backup up these compressed backup files so that I have a redundant copy. You never know when you need that old code.

Frustrated with the way you wrote your existing app and how hard it is to improve it? Fine. If you have the time, then classify it as a "prototype" and rewrite it. Sometimes there's great joy in rewriting something along with having a backup of the old one so that you can use it to demonstrate certain features you want to re-implement in the new application.

Put your most visually-complex page out on the web on a slow server, and test the download. Does this cause your page to download stuff that's messy and then all of a sudden this snaps together, creating an unprofessional experience? If so, then you've done something wrong and you need to rethink how this page is done or investigate the CSS and Javascript as well. You might also want to run it through a tool on the web called HTMLTidy to see if that fixes at least the HTML of it.

Before you roll that app out, you should at least test it on Windows, Mac, Fedora Linux, and Ubuntu Linux. You should make it work best in Firefox and make it work okay (but may not look 100% as visually appealing) in IE. Never use IE-specific HTML or Javascript code! Also try different monitor sizes. I've found that the best font is 11px for regular font, and 8pt or 9pt on everything else that I want smaller. Note I must use "px" on the 11px, and "pt" on the smaller stuff, in order for it to come out perfect to my tastes on the web.

Create a single error page where you will send users if they do something wrong in the application or if the application is misbehaving. That way, you can troubleshoot the application a little better.

Use a single Javascript file to store all your Javascript, and use that extremely sparingly. This reduces dependencies and increases your manageability of the code.

Create a class called "web" and stick all your web related methods inside like page redirection, form reads, etc.

Create a class called "strings" and stick all your string related methods inside too. This will provide a way for you to not have to repeat as much string manipulation code.

Don't forget that you need to account for use of your application simultaneously across multiple timezones and you need to accommodate this. You also need to ensure you use a decimal for real numbers in the USA, but it's a comma in Germany and a few other countries. There's a few PHP routines to help you with this, so consider that.

PHP6 or PHP7 Should Have Some Improvements

I have used PHP4 and PHP5 awhile now, and I can tell you that I am still always grabbing the manual to understand the sequence of function parameters for String Library functions. In some cases, if you have a haystack, needle, and a source parameter, you may have to reorder these with one function, and another way with another function. Instead, I call for standards here. Make everything consistent.

The same goes for the date and array libraries, but I also want to state that the date library badly needs a DateDiff() function and it also needs to be powerful enough to handle different timezones along the way.

All three of these libraries simply have too many functions. They need to have a slightly reduced set with a wider array of functionality.

Of course, I don't want to break old code, so I'd like to see these introduced as new libraries, such as "String2", "Date2", and "Array2", for instance.

And how many of us would like to be able to replace "->" with "." (optionally, with perhaps something like PHP8 only supporting ".")? How many of us would like to see a requirement of "." be used when a period is used to concat sentences, thus improving readability?

Speed Up Your Next Software Project with the "Morale Project Plan"

Working on software and falling behind on the project schedule? Is your customer frustrated already? Try my gameplan. It may improve the morale of your customers as well as your developers, and may unstick a stuck project.

  1. DEMO. You really need to think through all the nuances of the app. Sometimes projects are mired down because of discoveries. If you have time, use a slideshow drawing program to build sort of a demonstration of how the application would work, or throw it together as rapidly and as sloppy as you can in web pages and static test data to sort of get the point across and think through those discoveries.

  2. TECHNOLOGY LAB. If you have an experimental technology or a few that may be necessary for your application, spend no more than 3 days per technology trying to work out the kinks and decide on the application's direction based on the results.

  3. FUNCTIONAL SPEC. This is really critical and I require one on all my applications. If I can't get agreement for time to iron out one, then I tell you that this is not a project I want to work on. Working with the stakeholders, write a functional specification to explain every required feature of the application. Spend no more than one day, initially, and then deliver it to the stakeholders as a draft. Let it resonate on the mind a couple days, get some feedback, and then conclude with a final draft on another day. Of course you'll have feature creep, I'm sure, but this will help minimize it a great deal.

  4. USE CASE. This is where you normally write down all the possible threads of traffic from users visiting your application to do a set of tasks. Instead of spending a lot of time on this, just think up on use case that would demonstrate the largest set of features, complete from launch, login (if you use that), and the path among your features until the task is complete. It needs to have a real world example, but not a long one. Spend no more than one day building this with the stakeholders.

  5. PROJECT PLAN. You need to build a project plan. Do you need to build one in a project application? No, actually, you don't. A spreadsheet will do just fine in most cases unless your stakeholders are used to interacting with people who have project applications. Of course you're probably going to slide a little on time, or have to make adjustments as more discoveries are made, but at least you have something to strive for. Here's how I do mine.

    • Start your plan by taking the functional specification and group features by page or screen in your application.

    • Now sort these features in chronological order that would flow along the path of the use case you recorded, such as login, come to a main page, click "New Ticket", fill out a form, post it, read it, update it, resolve it, etc. That's an example of your use case.

    • If you have previous projects you have done, see if you can leverage that to decide how much time you think you'll need for each project step. Note also that if you give a feature task to someone else, you are probably going to need to tack on 2 extra hours per feature, maximum, for everyone you pass on. This isn't always the case, but is usually the case in my experience.

    • If you don't know how much time a task will take, then give it 4 hours and let the stakeholders know which ones are slight unknowns. I recommend setting up checkpoint times with the stakeholders to explain increased productivity or the need for more slack time, so that you can come to a more realistic timeframe for a project conclusion. You'll also need this on the next project you do.

    • Now add up the total time and divide it into sections of (A) 20%, (B) 50%, (C) 20%, and (D) 10%. What do these letters and numbers mean? Well, before I tell you these numbers, realize that you will be testing your application as you do each feature, so testing is already built-in. As for the numbers and letters, these are sections of the project. The letters are the project section, and the number is the time you will spend to complete that section. The project will move in alphabetical order with these sections, starting with A, and you will have checkpoints in between except in Section B, where you will have a checkpoint before it, in the middle of it, and at the conclusion of it. The checkpoint will be when you meet with the stakeholders to explain progress and discuss problems and solutions, along with risks and risk management. In Section A, you will rapidly write the software to implement as much of the Use Case that you recorded. HOWEVER, don't get mired down in the tough, difficult features of this Use Case -- turn it out as best you can so that you can deliver a good customer demo at the first checkpoint. In Section B, AND THIS IS KEY, this is where you will resort the project schedule by uncompleted features that will provide the largest visual contribution to the project. For instance, if I'm writing a criminal records search program, then I might sort to the top of this list the administration pages because, as an example, they might provide a large set of features that the end user (in this case the administrator) visually sees. I might follow that with an options page where end users can choose a whole variety of search options, or a calendar where I can see when my lengthy query requests might be processed by other company departments. It's all up to you to decide this. What Section B focuses on is programmer motivation so that they will feel like they're getting something done and will make the customer feel more at ease during checkpoints. However, saying this, realize that Section B is there you also do not get mired down in difficult code. Instead, you simply try to knock out functionality on an 80% functionality per feature rule. Section C, however, is a bit tougher. This is where you go back and complete the 20% functionality on features that you did not implement completely. Section D is where you do final testing and completion of the application.

    • Based on what you discovered by the process of building these sections, adjust your project schedule timeline so that it accommodates these sections properly. You should also adjust the times if necessary.

  6. PIXELS. Some developers I've interacted with worry about how they're doing something as small as whether it's the right number of pixels in width in a graphic element on the screen, or the minutia of how they implement an OOP concept. If you're in Sections A and B of the project plan timeline, this is not where you want to permit this to happen. Instead, let that happen in Section C. Otherwise, you may lose developer morale and cause timeline fear with your stakeholders.

  7. DOCUMENTATION. Some people like to document the application as they go. I find this quite aggravating and disruptive to the train of thought to developers. Besides, with the usual feature creep and discoveries of problems that require workarounds, there's a lot of wasteful time that's going to occur, rewriting the documentation. Instead, I prefer to bring in the tech writers to write the help files (or pages) along with the hosting documentation, installation documentation, reprogramming and systems integration documentation (should you be building a kind of SDK framework like your own CRM package), administration documentation, end user usage documentation, and troubleshooting documentation. Of course, you'll need to calculate this ahead of time and include it in the project schedule.

  8. FOLLOW UPS. When the project is complete and is implemented with the stakeholders, regroup and record those lessons learned, reusable frameworks, technologies, and ideas for future projects, and try to record how long it really took to complete each task on the project schedule. Consider also, if this is applicable, how long it took for a new developer to catch on while working with you on the project, and how the timeline must adjujst for that. Going forward, reuse this information and it will really help with your next project plan.

  9. GETTING FASTER. On your next project after this one, I can almost guarantee you that if you reuse large chunks of old frameworks, technologies, and concepts from previous projects, and reuse key team players from successful projects, you can probably shave off 2 weeks off the time it takes to complete your next project.

  10. THE NEXT VERSION. On your next version, the stakeholders will likely have more features they want to add, or to rework problems on existing features. I recommend that you do not accommodate all those in the same version. Instead, split this out over two versions. Give the customer 80% of what they want in the next version (1.5), and the 100% of what they want in 2.0. Why? Because you'll probably want to rewrite the application between it's current version and version 1.5, and this will take a good amount of time. You'll probably want to make more readable code and increase application performance. Do you need to tell the stakeholders this, though? No, you don't. Just let them know that you'll release the package twice so that they can be functional with 80% of the new features initially, and then 100% of the features eventually.

If you're skimming this, the most important thing I think you can do is to follow the rules I have specified for a Section A and Section B in the project. Section A focuses on the most common stakeholder walkthrough scenario and trying to provide at least 80% of that functionality, not getting mired down in the tough parts. Section B is where you help the developers overcome potential frustration with the application where they may feel it's too tough to pull off on the specified timeframe, or may lack motivation simply because they're overworked. Section B is where you start knocking out features by their largest visual contribution. The more of these you accomplish, the increased morale you will have with the developers and with the stakeholders. Everything else is where you sweat the small details and fix the remaining bugs.

I also believe in a rapid prototype, a technology test period, a simple use case design, a project plan, checkpoint periods with the stakeholder, documentation at the end instead of being integral with the project, and follow ups to identify ways to get faster on future projects with reusable frameworks, technologies, and concepts, in addition to the potential to reuse certain developers. I also have a unique spin on how to implement the next version so that you can have more readable code and a performance boost in addition to whatever the stakeholders want.