For fast page prototyping, these css libraries (i.e. grid frameworks) are very useful.  I did notice many issues when attempting to use more complex layouts – there is little room for any deviations, such as adding borders (Blueprint in particular)!

That is when I began adding float-fixes and other css classes to compensate for the issues inherent in these CSS frameworks.

This begged the question - did this truly save me time over a custom css framework based on the specific page layout?

Yes, I do believe it did save time.  The basic page structure can be created super-fast.   I didn’t have to worry about any heavy lifting just to get a container, subcontainers, and ribbon menus aligned and floated properly.  It was just a matter of adding a class definition for the element (<div id=’mydiv’ class=’span-7′>).

I will go into more detail as time permits, and I am going to try the YUI layout grid system.  Then I will do a comprehensive analysis of the features and drawbacks of each.

I will also cover how the following jQuery stacks integrate with each framework:

• jQuery UI
• jQuery plugins

Thanks,

Vic.

Page using the 960grid framework – many jQ features – check out each tab.

Page using the blueprint css framework – interesting MAC-like menu (hover over the solar system planets)

Another BP css page – sales page

chown – change owner of file system resources on Linux/Unix systems

To change the owner of a file name ‘myfilename.jsp’, do the following:

sudo chown jamessmith myfilename.jsp

To change ownership AND group for All directories and files below the current working directory:

sudo chown -R jamessmith:wheel ./ .*

It IS a CAPITAL R ( – Recursive)  and there is a space between the ‘./’ and the ‘.*‘

NOTE: chown can be a very dangerous command – it cannot be undone.  Exercise caution when changing ownership on files/directories en mass without a more targeted wildcard (e.g. “chown  meuser:mygroup *.jsp” will change ownership of only .jsp files in the present working directory – these are NOT system files and will not result in a system-wide error – though they may mess up your Java App server )

What we all must do as an employee or independent contractor or corporation is file the proper tax forms when they are due.  Don’t be late or you may incur a penalty on top of what you owe.

A start to creating a business entity is to decide on what form that business will take – sole proprietor, independent contractor, limited liability corporation (LLC), S-Type Corporation, or a full-fledged C-Type corporation.

Many consultants would opt for the sole-proprietor or LLC – the simplest forms that require the least administrative overhead.  To limit personal liability you must choose other than a sole proprietor which requires registering with a State as a corporate entity.  All this info is covered at the IRS website and others (legalzoom.com).

The EIN, or Employer Identification Number, is a number you receive from the IRS that is associated with your business.  This allows you to use this number in place of your social security number.  Best news – it is FREE and VERY EASY to acquire.

Get your EIN here: http://www.irs.gov/businesses/small/article/0,,id=102767,00.html

Now, scroll down near the bottom of the page and click the Apply Online Now link text (or use CTRL-F and search for this text).

Click here to start the process to acquire your EIN

That is it – Just remember to ALWAYS use your EIN in place of your SS# whenever possible, file your requisite tax forms ON TIME, and enjoy your newfound freedom (and responsibility) as an entrepreneur!

Vic

During the interview, I noticed there was the personable and relaxed atmosphere.  The company was comprised of individuals who had worked together for 12+ years.  Even so, as an outsider, I felt very welcomed.

Being used to more formal environments, this was going to be a welcome change; at this small company, there appeared to be a very hands-off management style.

After doing my very best to acclimate myself to the new code environment – a proprietary framework written in Java/J2EE within - using Eclipse (Helios) , I got down to work creating JSP pages, integrating jQuery (jQuery core and jQuery UI, and plugins – validate, default-value, alphanumeric, extjsoncookie, simplemodal).  The documentation for the custom framework as well as the assigned project was very scarce, consisting of a few use-case documents (no diagrams, just words).  The data schema was ‘evolving’ during the project, and, the data definitions and relationships were verbally defined – difficult to reference

All in all, not enough documentation to get down and dirty with a project that had a very fast timeline.  There were 3 complete site redesigns (aka major changes)  in 4 weeks – just when you get progress, you have to start from the beginning.

What I learned from this experience is:

• Clear, concise, and complete documentation is VERY important – not just words, but diagrams (use-case, process, flow, data, etc) – for any web application.  Smaller companies may not necessarily have the resources to accomplish this in a meaningful way, so be sure to set time aside upfront to create the essential docs to keep your team productive.
• A large enough team to bounce ideas off of is a tremendous asset – 3 or more developers working together with different skill sets is, in my experience, a minimum number - when there is a tight timeline.  That provides you with the necessary division of labor – MVC.  If time is not a primary factor, then a team of one front and one back-end developer would suffice.
• Having the developers intimately involved with the evolving design (database, page flow, SEO, UI, etc) benefits the company greatly.  There is an internalization and participation with the requirements that adds value during the code creation process – the more you know, the more you can do.
• Timing is critical - having the third-party designs ready BEFORE a developer gets on site, a development path defined, class and data definitions documented (particularly with a custom framework), and a team of resources that are available at a moments notice for any roadblocks that arise.

The working environment and culture at the small company was far superior to that of a large corporation for my personality and work style.  I was lucky in two more ways – the company president was exceptionally competent and creative (with a tech background), and the lead Java framework developer was a very gifted programmer.

When approached to take on a project with a speedy timeline, it behooves the consultant to weight the pros and cons of working with any business entity.  Before agreeing to consult:

• review the available documentation for the project -
  • are they concise, appropriate, and cover the breadth of the project?
• get a list of assets you will have ready access to during the various phases of the project life-cycle.
  • who will you be able to contact for business/marketing and technical issues outside of your area of expertise?
    • Business analysts, project managers, content experts, etc.
• make sure that the budget is realistic and you will not push the project over that thin, and sometimes arbitrary, profit-margin.
  • You don’t want to get on a sinking ship – if the budget is not realistic, let the company know.
• is the time-line reasonable/attainable given the above information?
  • If you see a lack of  any of the above attributes, you may be wise to walk away IF the company is not receptive to scaling back, adding assets, or proactively creating the necessary documentation.  If they want to understand and are willing to alter core aspects of the project, you may be joining a winning team that extends beyond this project.

When analyzing most things in my life, I use the simplistic who, what, when, where, how, why matrix.  That, I will define in a later blog – if it even needs defining

Thank you for reading – Vic.

As with every framework, there are issues with the documentation being too light or too heavy – seldom just right.  CodeIgniter documentation is excellent – once you get past the first couple of days digesting the syntax of the framework.

I was attempting to use the ‘directory’ helper.  This is a helper composed of a method that gets the names of files (and subdirectories) within a path and populates a multi-dimensional array with the results.  Two lines of code rather than around 10 for a pure PHP version that has the same features.

The key to getting this method to work was using the relative path and not an HTTP request.  If you use the base_url(), it will not work.  For my need, it was simply hard coding the path into my code:

$dirPath = "./this/is/the/directory/to/scan/";

$this->load->helper('directory');

$arrDirList = directory_map($dirPath);

Then, I used

foreach ($arrDirList as $key=>$value) { ... }

using the $key as the directory names to build my anchor tags and name the link.

foreach ($themeFiles as $key=>$value)                {

I had originally used a

$dirPath = $base_url() . "path/to/directory/"; // BAD X X X

Thanks, Vic Russell

First, be sure to include the appropriate jquery libs – jquery base and the jquery ui.  Also, the jquery ui tabs lib must be included – this is usually done through jquery.ui.base (containing only @import directives [@import url("jquery.ui.tabs.css");]).

When using the jquery ui library for tabs, you must create tabs using an unordered list and list items containing <anchor html elements:

<ul>
    <li>
        <a href='#tabs-1'>This is tab 1</a>
    </li>
    <li>
        <a href='#tabs-2'>This is tab 2</a>
    </li>
</ul>

You must also wrap the tabs in a container that is bound to an object reference and listener that implements the 'hidden' jquery ui tab classes on your custom tab.

Now, wrap the ul in a tab that will not close until the content panes are defined....

<div id='tabs'>
<ul>
    <li>
        <a href='#tabs-1'>This is tab 1</a>
    </li>
    <li>
        <a href='#tabs-2'>This is tab 2</a>
    </li>
</ul>
...
<!-- close the 'tabs' container>
</div>

<div id='tabs-1'>
    This is the contents of tabs-1
</div>

<div id='tabs-2'>
    This is the contents of tabs-2
</div>

<div id='tabs'>
<ul>
    <li>
        <a href='#tabs-1'>This is tab 1</a>
    </li>
    <li>
        <a href='#tabs-2'>This is tab 2</a>
    </li>
</ul>
<div id='tabs-1'>
    This is the contents of tabs-1
</div>

<div id='tabs-2'>
    This is the contents of tabs-2
</div>

</div>

<script type='text/javascript'>
// listener for profileDemogForm
$(document).ready( function() {
$(function() {
    $("#profileTabMenu_id").tabs({
        collapsible: true
    });
});
</script>

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.min.js"></script>

<link type='text/css' href="js/jquery_ui/jquery-ui-1.8.2/themes/base/jquery.ui.all.css" rel='stylesheet' />
<link type='text/css' href="js/jquery_ui/jquery-ui-1.8.2/themes/base/jquery.ui.core.css" rel='stylesheet' />
<link type='text/css' href="js/jquery_ui/jquery-ui-1.8.2/themes/base/jquery.ui.theme.css" rel='stylesheet' />
<link type='text/css' href="js/jquery_ui/jquery-ui-1.8.2/themes/base/jquery.ui.base.css" rel='stylesheet' /><<<

Some tips:

You can name a jquery tabs container anything - you just have to use that for the content pane tabs.

<div id='myTabs'>

Each bookmark reference would then follow the following semantic:

<a href="#myTabs-1">  and <a href="myTabs-2">

The -1 and -2 (dash 1 and dash 2) are very significant and must be followed for the jQ UI to pain these anchors as tabs.

content pane (aka: contentpane) the wrapper (named anything - I like contentpane or tabs_contentpane) that contains the container divs that further contain the html to display when the tab is clicked (in focus).

This content can be

• inline html
• an included page  using jQuery .load("url")
• a pre-fetched server-side include (<%@ include file='tabcontent2.jsp %> or <? include("filename.php") ?>

- First, Agile sounds cool. There is an inherent power and affinity to like the word ‘agile’, to say ‘I am agile’, ‘we have an agile development team’, ‘our business model is agile’.  The power in a word cannot be understated – business wants to be agile; developers like to be seen as agile.

A few operational definitions. Agile software development is short term goal oriented – component directed. The idea is to get a bunch of software developers working on a project by picking components (‘stories‘) from a master list of ‘backlog’ items and completing those individual components within a short period of time – called a ‘sprint‘. The typical goal of the sprint is a complete sub-component, one that can be demonstrated during the ‘retrospective‘ as a stand-alone element.  Some shops even demand that these components are ‘go-live’ ready.

The first deficit with Agile project management appears when there are components that are comprised of multiple smaller sub-components that are not separated into different stories. For example, a form page.  A form page is composed of the following: the HTML wrapper, CSS formatting, the form proper, business rules for managing the form input/processing/output, form content validation and security, other user interface components, data definition/acquisition layers (db abstraction/ORM), and presentation components. There may be Ajax components to the form, as well as validation, and visual/auditory Fx via JavaScript.

The failings of Agile comes to light where ‘expectations’ are concerned. Business expects a completed components at the end of a sprint. Anyone who has designed and developed a full blown web application (as opposed to a ‘site’, ‘page’, or ‘component/widget’) understands the iterative nature of such a ‘process’. The final result is most often a group of components that can be reused to simplify program maintenance and improve program performance through re-factoring to optimize the total application developed over the duration of the project.

I think the best way to compare Waterfall with Agile is that Agile is concerned with ‘events‘ and waterfall is concerned with the flow of app development that results in a completed product – the  ’outcome‘. Conceptually, both are correct – an app is a bunch of ‘events’ that interact to produce some result, and, an app is a business process that must be satisfied through a series of components that elicit a specific outcome, or ‘result’.

Sprints are like a course that is made up of a bunch of quizzes with no final exam.  It is the accumulation of grades over the course.  A waterfall project is a course with NO quizzes - only a final exam, and, maybe a mid-term.

Waterfall methodology emphasizes pre-defining all components so, in theory, the development portion is very short lived.  More time is invested in defining the components and laying out the look and feel of a site than is actually set aside to code them.  Planning is everything.

What often time occurs using the waterfall method is, in Agile parlance, a bunch of backlogged items become evident very near the end of the project.  For developers, it becomes a ‘marathon’ to complete the project on time – often times with few, if any, functional components to demo for stakeholders (ie business owners).

Other deficits in the waterfall methodology are scope creep and the effects of incorrect estimation of build time (coding & system administration).  Since the planning portion is so long, items are often added that should extend the duration of coding, but seldom do.  Most projects have a go-live date that is seldom altered, even though the scope of the project increases.  As a component is added or altered, reality would dictate altering the estimated due date – but that seldom happens.

<psych aside>Human nature, for many people, dictates that we want to satisfy the needs of others – particularly superiors or people who can advance our careers.  The waterfall method plays on that human tendency to the advantage of the stakeholder at the expense of the development team.  It is difficult for many of us to say an unequivocal ‘NO’ to the VP of marketing or sales when they have a ‘really good idea’ for a feature that will add a developer-month to the project.  The problem arises when the project is past due, and that feature that the VP loved so much three months earlier in the planning stage is all but forgotten – it no longer carries the same emotional power it did earlier.  All that matters now is that the developers are late delivering the project.</psych aside>

Pure scrum can be effective when modules are very compartmentalized – there is little co-dependence on other modules.   It becomes nonsensical to use Agile when the overall system has many dependencies UNLESS there is an agreement that modules will be enhanced and integrated at a later date when the ancillary modules that, say, perform form validation, are complete.

When you get right down to it, Agile is a good way to reduce the upfront cost of a project and put most of the design and planning on the developers – which is, in my opinion, a good thing.  A less is more approach that can be effective for the largest project, so long as the stories reflect reality.

vr

There is a file in the home directory of all users called the .bashrc file (the period is not a typo – it is a hidden file).  Add the following line to get the ‘history’ output with a time and date stamp:

export HISTTIMEFORMAT="%F %T "

You can enter this at the command line and then run the ‘history’ command to view the new output.

[root@localhost vrussell]# history
531  2009-12-27 21:19:35 cd ..
532  2009-12-27 21:19:36 ls -a
533  2009-12-27 21:20:40 history
534  2009-12-27 21:20:53 export HISTTIMEFORMAT=”%F %T “
537  2009-12-27 21:53:05 grep -lir ‘bashrc’ *
538  2009-12-27 21:53:13 history
539  2009-12-27 21:53:15 clear
540  2009-12-27 21:53:32 vi testScript.sh
541  2009-12-27 21:53:39 history

export HISTSIZE=4000

Another useful history setting is the number of commands that are stored in the .bash_history file.  The default appears to store the last 1000 commands – increase that number to 4000 lines or more.  Grep or [CTRL] + r can filter the results effectively.

. bashrc file entries ( using vi/vim )

# User specific aliases and functions
# display date time in history output
export HISTTIMEFORMAT="%F %T  "
# Increase from default 1000 lines to 4000 lines
export HISTSIZE=4000

# User specific aliases and functions
# display date time in history output
export HISTTIMEFORMAT="%F %T  "
# Increase from default 1000 lines to 4000 lines
export HISTSIZE=4000
alias ll="ls -ltr"

Edit your .bashrc file using pico, nano, vi, vim, emacs. If you can access files via Windows, use Notepad++ (download Notepad++ from SourceForge)  and not Windows default Notepad.  Notepad ++ lets you save files using the Unix line break.

There is a time to sow, and a time to reap…

This Biblical verse is true in agriculture, personal life, as well as merchandising and marketing.  You can have the best new ‘feature’ to your web site, but the timing of the release should be carefully considered.  If your feature is of minimal impact to the navigation and overall familiarity (look and feel) of the site, then there is little risk in implementation.  If, however, you are planning a complete redesign of the presentation and business logic layers, you may consider the time of year for the release.

Why: One retail chain that I had worked for decided that their website needed an upgrade.  That was an understatement - the existing site was very dated in both style and functionality.  Many features that the underlying web framework offered were inaccessible due to a prior rushed upgrade that ‘broke’ what is a very robust J2EE-based framework.  Business and IT knew that a complete rewrite was the only way to efficiently keep the site extensible, maintainable, and scalable.  The initial launch date was early September, with a fudge factor of a couple of weeks.

As the months of planning a preparation, design, coding, and testing went by, it was clear that the target date would be missed – by about 2 months!  That brought the time of the upgrade to the apex of annual holiday sales season.  While this may initially sound like the perfect time to release the site to the customer base, a little more thought might suggest that the opposite is true – it may be the exact wrong time.

Who: Humans are creatures of habit.  We like familiarity and loathe what is unfamiliar and different.  We often come to embrace the new and different over time, but our initial reaction to change is typically resistance.  Fortunately, the web offers most of us scores of choices when we are searching for information or products to purchase.  There are always options.

If my favourite tech site (http://www.tigerdirect.com) changed the complete navigation, design, and business logic, I might consider purchasing from my second favourite site (http://www.newegg.com).  While I do not like the look and feel of New Egg (a personal preference, not a critique on their site design), I have grown use to it and can find what I need fairly quickly.  Tiger Direct will lose my business until I have the time and need to re-learn how to find products.

NOTE: Tiger Direct has not changed their site; it is easy to navigate, has great pricing, and their product delivery is stellar.

What: Data translation is very tricky, and more often than not, it results in some type of corruption on the first attempt.  There are many ways to insure that data will be intact after the conversion, but none are 100% reliable.  The rule: always plan for a data layer error during and soon after an upgrade.

When: When, then, is the optimum time to do a complete site upgrade?  During the least busy time of the year.  For e-commerce sites, that time is often between mid January and the end of April.  Plenty of time to work out the kinks in the new system.

Where: Do you have the resources and skills to perform the upgrade internally?  Is there adequate personnel in house to both maintain the existing site and code the new site?  Do you have adequate testing personnel, with the proper testing tools, to insure that what is being done will really work?  Is outsourcing your best option?

These questions should be answered objectively and without regard to pride, personal advance, or budget pressures.  A team that is not sufficiently trained or does not have the time to code on such a scale will experience mistakes, delays, stress, and, ultimately, failure.  Augmenting an in-house team with consultants who are experts in e-commerce is another option.  This works only if your personnel are eager to, and have the capacity, to learn the details of an e-commerce framework.  It is one thing to maintain and enhance a site, and a completely different process to code a site from the ground up.

How: Do you flip a switch when performing a complete site upgrade, or do you gradually test the site with a subset of your visitors?  Obviously, you direct a percentage of your customers to the new site to assist in production testing.  You can ask customers to ‘opt-in’ by presenting them with a link or popup when they first arrive at the site, or, redirect nn% of the traffic to the new site automatically.  The opt-in approach gives the customer control, which often results in a positive reaction.

Along with the opt-in, provide the customer with the option to revert to the ‘old’ site if they cannot find what they are trying to purchase.

Once the guest has visited the new site, ask them to fill out a 3 – 5 question feedback form.  One of the five questions will be a text box so they can give you as much feedback as possible.  Again, if they are involved with the process, they will more likely embrace the new site, over time.

As a matter of safety, the cart/checkout process might remain as-is initially.  In other words, your marketing and merchandising of products can be upgraded, but once products are purchased and the customer is checking out, the familiar cart gives them a sense of security.  Keeping this critical component the same during testing reduces the likelihood of abandonment and order corruption.

Conclusion:

Given the strained economic climate, there is an ‘out’ if the new site fails.  The economy can be blamed over the timing of the upgrade release, and no one will be the wiser – unless the site is completely down, you look at the analytic data and see that the abandon rate increased during this period of time, that orders were not committed to the database, or that products were out of stock and still presented, etc.

So…

• Timing is (almost) everything.
• Be objective – new is not always better.  Emotion, self aggrandizement, and pride should never drive a business decision of such magnitude.
• Research your customer base to determine what they will accept (and when).
• Look at your competition and research their successes and failures concerning feature enhancements and upgrades.
• Dates are numbers that exist on calendars – they can be changed.
• Skills can be learned, but complex skills often cannot be learned quickly with great aptitude.

vr