Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Do both (Score 1) 119

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.

Comment: UV and vibration (Score 1) 478

by trajano (#46277459) Attached to: Ask Slashdot: Anti-Camera Device For Use In a Small Bus?

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.

Comment: Be professional (Score 1) 308

by trajano (#46141741) Attached to: Ask Slashdot: What Do You Do If You're Given a Broken Project?

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.

User Journal

Journal: New site

Journal by trajano

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
http://www.000webhost.com/676474.html

The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov

Working...