I really think it simplifies the use of the RSS to non-techie ppl and will provide huge value to your company!

When more you work with it, more fast you will develop

I agree with you, even though right now we have a server outside AWS for the svn and testing, we should, in the long run, put it into AWS so that it uses the exact same image.

Thanks for the comment man!

In the corps I worked in Spain they usually have the environment for developer (Eclipse, Webshere, etc…), then a development server, an integration server and production server. Some even have more environments. But actually there is ususally problems going from one environment to another, no matter how hard people try this not to happen. So, my advice would be if you don’t have too many human resources, go with just development server and production environment. I mean development server not the environment in the machine of developer.

If you have many people working on the project then play around with environments, integration ones are usufull, even more if you have domain issues with other web services, providers, etc… that need to replicate a production server.

Another problem with environments is that when many projects are uploading stuff to for example a development server, admins sometimes needs to shutdown stuff which leads to people not being able to test their apps in the development server. Amazon could help here, creating an instance for the people on that project and have many development instances only used when analyst or project managers are testing, etc…

Agree on most, small integration servers are indeed a need. Go through the path of Development server in the developer machine, then integration with more or less the same environment, and production.

With Syntax I simply use python plugin for Eclipse, that is take care of.

In deployment I use versions for all content. That is, a CSS app.css would go to S3 as app-0001.css. These files are compresses and long times in the future. I can version independent modules (JS, CS, Themes, etc…). Integration server and development server goes with app-0000.css with no future dates and loading normally. Every time I do a change in a module, generate a release in that part of JS, CSS, and the HTML will call that file. I have a deployment script that takes care of this. Loading of heavy JS content is faster this way for users visiting more than once.

I do a monitor alert, very simple, that a search is accomplished right and therefore front and back are communicating, web servers ok and services. But this area is never enough, last night found that home page had an error and did not notice (I am playing around with a new front release) and did not have development debug in Django to False, when error message shows and Email is sent with error. Still, the better monitoring you can afford the better.

I’m doing a little research for my big project and looking for some good key-value db with success stories.

Yeap, I know TC is really good. But what python bindings are you talking about? It’s really important for me, so I’m here and waiting for your answer :]

Thanks.

Redis seems very sweet. Here you can find a nice post about TC and Redis comparisons: http://amix.dk/blog/viewEntry/19458

In my case I feel TC is slightly better suited for Inkzee than something like Redis, although it’s nice to know about it. I might even give it a try sometime in the future.

Another post that talks about Voldermort, MongoDB, Redis ans TC: http://randomfoo.net/2009/04/20/some-notes-on-distributed-key-stores

As usual it’s a matter of choice to fit the problem at hand. For now, TC and TT have performed extremely well under my tests. Let’s see how it holds out.

Btw, TC has a bunch of php clients, including 2 I talk about in another post: http://blog.inkzee.com/index.php/2009/06/28/tokyo-tyrant-and-some-numbers/

Nevertheless, implementing a basic php client is quite easy. You have all the protocol stuff on the TC site

Thanks for the comment!