I’m happy to announce that I’ve almost finished work on the next version of BambooInvoice.  I have to say, I’m very happy with the new functionality and features.  Aside from the usual bug fixes and code modifications, there are some very substantial architectural changes - namely, the addition of itemized invoicing.

In order to make sure its running smoothly, I’d like to solicit some people willing to take part in beta tests.  In order to participate, you’ll need to be comfortable backing up and restoring your database.  I’d also love to get some non-English speakers into the mix.  If you’ve been wondering how you can help out with Bamboo, this is it.  Please contact me.

Itemized Invoices

This was far and away the most requested feature, and I’m happy to add it in.  If you don’t have a use for itemized bills (I’ll probably never need them), then I’m hopeful that the feature will get out of your way totally, but if you do need them it should be a seamless transition.  A bit of history here - if you’ve used a previous version of Bamboo, you may have noticed me slipping in a field into the invoices table called “itemized”.  This is because in the old system, all invoice information was in a single table (“invoices”) that included: id, invoice_number, work description, amount, and now “itemized”.  This works great for an invoicing system were every invoice corresponds to a single piece of work.  But with “itemized” invoices, it sucks.  So my intention was that I would serialize itemized things and store them here.  I spent about a week on and off getting this running.

It was awful.  I wasn’t happy with the way it worked… I found it too slow, very limiting.  So I decided to change gears, and worry about the front end for a while.  I started and stopped no fewer then 3 separate approaches before I finally got one I was happy with.  I spent a lot of time with javascript working through DOM node cloning and other things I wouldn’t wish on any of you.  When I finally got to a solution I was happy with I flipped back into backend work… oh yeah… that damn serialized array again.  So I started getting depressed.  I was trying to use arrays and bend my system to do something it was not built to do.  If I were building it again from scratch, the invoice items would be in a separate table, but I was concerned about all the legacy data and people using Bamboo who would need to migrate.  But since I wasn’t happy, I just bit the bullet and moved all that stuff into another table (“invoice_items”) and spent an afternoon writing a migration utility that runs automatically when you update Bamboo.

After it was done, I was “OMG Ponies!”, this is perfect!  Sure it required a major re-architecting of the invoice functions, but now that it works I’m pretty happy.  Itemized invoices are a breeze, and you can even control taxes on individual items.  I’m much happier with the flexibility.  All in all… its a big improvement.

Utilities and Advanced Settings

Let’s take a look at a few of the things to expect. There’s a new menu item in the “root panel”.  Under it, there are 2 new options; PHP Info, and Database backup.  The PHP Info is to help me with giving support (if you have read the BambooInvoice Forums, you’ve probably noticed the first thing I always ask people to do when troubleshooting it to upload a phpino() file.  This just makes it easier for all involved.  I shamelessly stole the code from ExpressionEngine on that one.  Hope I’m not violating any copyrights there (don’t sue me Rick!). There is also a database backup utility for… um… database backups.  The backup utility is currently MySQL only - and in fact, with some of the new query-acrobatics I needed to do, I suspect the whole application is nearing the point of me not being able to say it supports multiple databases any longer.  I’ll need to look more into that.

Next up is the settings panel. The settings panel has undergone a major User Interface (UI) change.  The result is (I hope) a more streamlined, and easy to follow panel.  It actually offers more choice then before, including an option to save your invoices to the server as you generate them, as PDF files. The image is actually a link to a quicktime movie.  If you’re interested in seeing what it looks like, take a quick watch - the whole thing is only about 15 seconds or so.  If you watch it, you’ll see an advanced settings tab. 

Bamboo now offers the ability to save copies of your invoices online in PDF format.  Personally, I’m not sure I’ll ever use this feature, but it was specially requested, and so I include it here.

There are a few other notable UI enhancements. Here you can see that invoices are now separated by month in an effort to make a quick visual scan of your accounts easier.  This turns out to really help when you’re trying to scan through the list.  I’ve had it in my local copy for weeks now, and when I flip back into the “old style” I wonder how I ever did without.

Community Input

Another thing that this release will mark is the first significant input from the community into the project.  BambooInvoice 0.8.2 is probably feature-rich enough for me, but the enthusiasm of the users has really kept me wanting to keep building. Itemized invoices, saving local PDFs, and many of the usability enhancements where user suggestions (thanks!).  Also, another language (Portuguese) has been added, proudly bringing it up to 7 languages.  Thanks Matt Finazzo and ELRafael! Some of the language translations may be inaccurate, so if you use Bamboo in a non-english language, please don’t hesitate to send me corrections or enhancements.  Or heck, other languages!

Private Beta

Yeah, same paragraph from above ;) In order to make sure its running smoothly, I’d like to solicit some people willing to take part in beta tests.  In order to participate, you’ll need to be comfortable backing up and restoring your database.  I’d also love to get some non-English speakers into the mix.  If you’ve been wondering how you can help out with Bamboo, this is it.  Please contact me.

Note: the specific subversion information in this post is now out of date. Please refer to the CodeIgniter Downloads page for the latest information.

If you’ve been following the CodeIgniter community, then you’ll know that some time ago, we made an subversion (SVN) repository available. Subversion is a version control system that we use internally to be sure we’re all working from the same page. The SVN is publicly available, and is committed to by 4 of the fine folks at EllisLab.  I’ve referred to it before, but I’ve never really talked about how to use it. Recently, there’s been some people interested in getting the latest and greatest CodeIgniter changes pre-release - and heck, why not, as there’s some fine work in there.  This post will talk about how you can use the SVN to keep up with the latest CodeIgniter changes.

First of all, the standard disclaimer: we make great efforts to be sure that the code in the repository is bug free and functioning, but as is the case with all “bleeding edge” releases, from time to time things may slip in there, so I don’t recommend you use it in a “mission critical” environment.

So, how to use it?  If you are a Mac user, there are 2 pretty nice graphical interfaces.  SCPlugin gets the most attention, but I really like SVNX. 

In windows?  Go for Tortoise SVN.  Integrates with Windows Explorer and has probably the most intuitive interface I’ve ever worked with.  In any event, pick a client ;)

Now create a folder on your computer somewhere, and rightclick to set up a new repository.  As your destination, choose “http://dev.ellislab.com/svn/CodeIgniter/trunk” which is where we keep our stuff.  Now your goto command is “update” and “show log”.  Update gets you the latest files, and “log” let’s you see what changed.  Here’s an example of the log file from today.

Notice that most times when we check something in we make a comment? Sometimes a change is so minor that we don’t bother, but in general it’ll help you stay on top of what is new in the repository.

Changes tend to come in fits and spurts.  You might see nothing for two weeks, and then a dozen changes in two days.  In general, anything particularly noteworthy will be discussed here (on this blog), so you don’t need to check it every day, but you might want to keep an eye on future changes yourself.

Welcome to the cutting edge! ;)

A few days ago, I wrote about the release of ExpressionEngine 1.6.1.  In it, I highlighted the “live look” feature, as a great new addition.  Live look allows you to preview a post within a template, rather than previewing only isolated content.  So you can see what your content will look like inside your template.  This is great if you have a future entry, or a post that you are leaving “closed” until you have a chance to finish it up.

But there has been a bit of confusion about how live look should work.  Essentially, all it does is load your entry into a template, so if you have a future dated entry, or a closed entry, it won’t be visible by default.  The solution?  Create a “preview” template, and take advantage of the status and show_future_entries parameters.  Essentially, make it look like this

I’d further recommend that you take advantage of Template Access Restriction in your preview template.  Without it, anyone who guesses your preview template will be able to see upcoming or closed content.  Probably a good idea to restrict it to the same member groups as your authors.

Happy ExpressionEngineering!

From Eric Barnes, a quick and straightforward summary of CodeIgniter and SimplePie.

Last night, with very little fanfare, EE 1.6.1 was released.

I tested 1.6.1 on this site about a week ago, and I’ve had no glitches, and there are a few very nice enhancements, mostly for me around usability and productivity.  With my clients, I love the Pages module that was introduced in 1.6.  In 1.6.1 it makes allowing them to update their own content and site that much easier!  Specifically, there is a new “live look” feature, so that instead of only previewing content, you can actually preview what the content will look like inside your design.  Brilliant.  Also, the pages table now offers the ability to have nested pages, which in at least 2 of the sites I’ve got, is a tremendous help.

Many of the rest of the 214 (yes you read that right… 214) feature enhancements and bug fixes address stability, speed and usability modifications.  All in all, great additions.

The update process is as easy as ever; just backup your data, upload the new files and run update.php.  Easy-peasy!  Um… you DO backup your data right? ;)

If you notice anything funny in this site, please do let me know!

I had originally wrote this as a response to a support request, and then wrote it up in the ExpressionEngine Knowledge Base as Times, Localization, and Entry Dates, but given the transition out of Daylight Savings Time (DST) this weekend, I wanted to repost it here.

One of the hardest areas of web applications to get your head around is the treatment of dates across various timezones, servers, and computers with daylight savings time (DST).  There are so many variables that ExpressionEngine can never be 100% sure of the proper time, and often the only answer is to experiment.  The wiki article Dates Explained may help in this.

Here’s the problem with time.  Imagine you and your buddies are trying to meet up at a set time, and you’ve all given me your watches so I can phone you at exactly 7 to tell you to be there.  When I get your watches, some of them are set 1 hour behind everyone elses (DST).  OK, confusing, but as long as I know that are observing DST I can account for this.  Now imagine that each one is set for a different time zone.  OK, also confusing, but I can figure that out also.  Now suddenly some of the watches stop observing DST (many hosts do), or start observing at different times.  Now I’m scratching my head.  I get a bunch of new watches, and I don’t know if they are observing DST or not.  Now some of the watches are simply set to the wrong time.  There’s also a master watch with the official time used for each day you want to meet your friends, and every day there’s a new way of officially adding and removing that hour.

Here’s how I have my system setup to give me accurate time on EngineHosting.  I’m in Toronto, so Eastern Standard Time.  Both my personal local time (under My Account > Localization) and my system time (Admin > System Preferences> Localization Settings) are set to Eastern time.  My “Daylight Saving Time” and also my “Honor the Daylight Saving Time setting associated with each weblog entry?” are set to “no”.  Partly this is to avoid the DST problem all together, but also I had originally set it this way as I was moving between hosts, and wanted fine control without needing to worry about what setup they had.  Without DST, this puts me an hour “behind”, so I set my “Server Offset (in minutes)” to 60 to make up for it.

When I post, the date and time under “date” is the exact same as my local time, and it posts to screen with that time.

If you wanted the time an entry was posted without any reference to the localization of the author, {gmt_entry_date} is what you want.

The date the entry was submitted in GMT. This variable is not localized for each user’s date settings.

You ever inherited a site done by someone else, and looked and the site and thought “what the hell where they smoking when they did that, and who gave it to the client making it seem like a good idea”?  C’mon you web-snobs, I know you have.  We’ve all done it.  Heck, I’ve done it recently.

There are two sides to every story

Well, I’m going to stop making any judgments about the quality of other people’s work unless I know the circumstances around how it got developed.  A day of reflecting on my own work has made me rethink things.  Yesterday I was working on a project, plugging away and I thought “hey, I’ve solved this problem before, let me go see what I did”.  So I pull out some old code, and next thing I know, I’m looking over some work I did some time ago.  I wasn’t super impressed. I found a series of nested if statements at one point, when really it could have been written in one line.  Is that the end of the world?  No, but it shows inelegance, and a lack of careful planning.  If this was someone elses work I would have thought “phfft, they’re lazy”.  Anyhow, I was disappointed, so I thought I’d fix it up and upload it for my (former) client….

And then it all came flooding back. 

• “Now, who was that client again….? oh yeah… them”
• “I had that working perfectly and then they changed the specs”
• “Golly, another new head of the committee… welcome to the team”
• “I remember that line of code… they actually threatened that if I didn’t have that working by the end of the day I wouldn’t get paid.”
• “But I’ve already changed that to behave the exact opposite way you want, after you asked me to, after you told me to change it back”
• “Design by committee is horrible, but design by committee when 3 of the 4 people who were spearheading the committee have quit or ‘moved on’ is death”

So as you can see… in a lot of the cases the slightly less elegant code was a result of a changing landscape. I don’t think I could possibly build to quality, when the idea of “quality” is a moving target.  In that case, a nested if just worked for me.  When you’re bound by the triple constraints of cost, quality and speed, then something has to bend.  If the client isn’t willing to sacrifice cost or speed, then quality is going to suffer.

So I’m no longer going to look at

and think “why did they even bother”?  Maybe the developer was dumb (that’s always a possibility), or maybe that variable used to hold other information, or maybe they were directed that way, or maybe the dev inherited other code that the client wasn’t willing to let them alter it.  Who knows?

Until I know the history and politics around why something was coded the way it was coded… I’m reserving judgment on anyone else’s work.

Oh yeah, and that inelegant client code I found?  I never did fix it up.