This event is a groundbreaking start for the software startup community in Edmonton.. I’ve had a chance to meet the organizers and it’s definitely folks who eat their own cooking and are pursuing startups of their own.

Working in startups can be isolating at the best of times… This is a fantastic opportunity to meet your peers and see where things are headed with events, and your input.

See you there!

Find out more at StartupEdmonton

Today I came across an article titled: Ten things to do before launching your blog.

It touches on some great points.  Some I knew, others were new and well well explained.  I have shortened the article to the main points below.  Click on the link above to read the entire article!

Study: Seek out the good people and follow them.

Start building buzz: Everyone should know that a blog is coming and they should be excitedly awaiting your arrival.

Secure the appropriate accounts: KnowEm.com , Google Analytics, Technorati, Feedburner.

Get your house in order: Put up a compelling call-to-action is you’re looking to secure emails for a newsletter. Take steps to make it easy for users to share your content, both via email and the social networks.

Content

Create a content strategy: Editorial calendars.

Seed content:

Decide: Ads or No Ads?:

Promotion

Build your promotional team:

Comment on other blogs, message boards and forums:

Respond to comments on your own blog:

One of the key things to keeping any successful web application running is ensuring you can keep one version running live (in production) while developing the next version… all without the two worlds colliding.

Below are some tips that I have found helpful.

1) Seperate URLs www.yoursite.com vs test.yoursite.com. you can also do www.yoursite.com and www.yoursite.com/development, etc.. You could also create a /beta or /staging..

2) Keep seperate databases, one for production, and one for development. Write a script that will copy your live database into a dev database. Keep one database for each type of site you create. (You may want to create a beta or staging database for your tester).. Do your own work in the dev database. If you change the database structure, save the changes as a .sql file that can be loaded and run on the live site database when you turn those changes live.

3) Merge features into your different sites with version control. In addition to using something like Subversion for source code management (which every site should have)., I am currently playing with a subversion setup for web apps that has my stable (trunk), one for staging, and one for development. Development tags + branches get merged into staging, and then staging tags/branches get merged into stable. Version control will let you manage your source code in any way you want. You will have to find a methodology that works for you and use it.

4) Consider build automation. It will publish your site for you automatically. Take a look at http://ant.apache.org/. It can drive a lot of automatically checking out your code and uploading it to each specific site as you might need.

5) Toy of the month: There is a utility called cUrl that you may find valuable. It does a lot from the command line. This might be okay for you to do in case you don’t want to use all or any of Ant. ]]> http://www.panesar.net/2009/03/09/how-do-i-run-one-version-of-a-web-app-while-developing-the-next-version/feed/ 0