Ya I still use it for my running my Linux servers, it does the job. Though it required an external add on to get it to run as a Windows Service. However, I used to not upgrade until they updated the Windows Service extension to work in any newer version.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
The use of JQuery allows us to bypass using CSS to make some visual changes to the HTML.
It will take a bit more preparation to create the template code that the students have to fill out initially though.
I would recommend doing both. There are significant advantages of moving some of the development/test tools out to the cloud. However, it should only go as far as development and perhaps first stage testing which is probably what your CTO has in mind.
There's no reason why each development project has to pay for the physical space taken up by *shared* development tooling such as Jenkins, Common Git Repository, JIRA/Redmine/Trac and some database and application server that is used for functional testing.
However, a proof of concept system must be present locally even if it is a limited capacity otherwise you'd be wasting a lot of bandwidth going back and forth.
It would also help to design your application architecture so that you can theoretically run everything on a laptop (and provide a powerful laptop to do it). For the developers.
If your'e an IBM shop, you may want to look at JazzHub to manage things for you.
I was thinking how about keeping it dark, while at the same have those UV light that they have in the bowling alleys to set the mood. Perhaps some constant vibration in tune with the music to prevent any stabilization of images.
Of course if you detect a flash you should take them out right away.
Normally the important part is things work on their target environment. So whatever approach you take does not matter as long as things will work.
If I am thrown into a new project, I start to do a few things if they are not available.
a) set up git and port the source code to my local git repository. This allows me to work in a version controlled environment that does not require me to show my intermediate work and experiments.
b) build it and make sure things do work.
c) create a test harness even if it is just to prove the welcome page works, I can add onto it as time goes by.
d) set up a coverage report to visually how the test cases flow through the app without stepping through a debugger (if you're lucky your language supports this, most of my projects are Java based so I have these tooling available)
Provide estimates. Don't say ASAP, always give a proper time, but not optimistic estimate. I tend to pad my estimates otherwise if something goes awry I would be accountable for them. I try to estimate based on a Jr. developer who is thrown into a project multiplied by two. However, if I do finish things sooner I let them know so the plans can change accordingly. If they want things sooner, still be firm and tell them that those are reasonable estimates given your analysis. They can choose to either accept them, try to allocate more resources (ideally) or kick you out (which is better than being burnt out)
Should your team grow, let other people know how you're doing things, there's no need to document every little thing, but be there to offer. Documenting everything you know will burn you out. As far as documenting things in detail go, I do make detailed install guides to get new developers up and running. However, that document ownership gets passed to the new developer for updates and refinements as things go.
After I left for Live Journal, I moved around again to Blogger and now I am running on WordPress on http://www.trajano.net/ thanks to
Link to Original Source