Jetty login basic authorization is not actually secure; it only concatenates the username and password and base 64 encodes. Anything that can be done in XML can be done in Java, but shouldn't always be.
If you get into hashes, you're still not particularly secure. Only when you start using salts in your hashes is it possible to escape the problem of malicious rainbow tables. And if your project is open source, then it's unwise to include your salt in the source which is going open, unless your salt generator is unpredictable. Cookie based sessions over SSL will follow logically when true security is needed.
Since iteration 1 is drawing to a close, we're planning to branch and continue development after we achieve our release candidate, so the candidate can be tested end to end.
I've been playing with EC2 for things unrelated to work, namely the git bash recursion script Maypole... which is still very basic.
Getting a working handover for the next team is an interesting problem. In general, good code explains itself, but the same doesn't really apply to build systems and to configuring local development systems.
Future TWUers: if you have Windows, dualboot Linux, ideally before development starts so you won't have to do everything twice. Keep in mind that Sonar and Twist sometimes don't keep up with refactorings of package structure and paths. Pay attention to our build monitor. And always, always check and update Mingle. Get everyone to the client site as early in the project as possible. Always invite the devs to the showcase but don't require attendance. Try to stack informative sessions immediately after standup. And remember that the buffet at the Mercurial is the best lunch you can find. Ask for feedback- it's pull, not push. Have a code review weekly and review your technical debt, but timebox it.
Apache Ivy is a .jar dependency manager, and it solves a lot of problems where we need several versions of one package for different functionalities. Without Ivy, you can get difficult to track errors if your .jars are called in an unexpected order.
If you get into hashes, you're still not particularly secure. Only when you start using salts in your hashes is it possible to escape the problem of malicious rainbow tables. And if your project is open source, then it's unwise to include your salt in the source which is going open, unless your salt generator is unpredictable. Cookie based sessions over SSL will follow logically when true security is needed.
Since iteration 1 is drawing to a close, we're planning to branch and continue development after we achieve our release candidate, so the candidate can be tested end to end.
I've been playing with EC2 for things unrelated to work, namely the git bash recursion script Maypole... which is still very basic.
Getting a working handover for the next team is an interesting problem. In general, good code explains itself, but the same doesn't really apply to build systems and to configuring local development systems.
Future TWUers: if you have Windows, dualboot Linux, ideally before development starts so you won't have to do everything twice. Keep in mind that Sonar and Twist sometimes don't keep up with refactorings of package structure and paths. Pay attention to our build monitor. And always, always check and update Mingle. Get everyone to the client site as early in the project as possible. Always invite the devs to the showcase but don't require attendance. Try to stack informative sessions immediately after standup. And remember that the buffet at the Mercurial is the best lunch you can find. Ask for feedback- it's pull, not push. Have a code review weekly and review your technical debt, but timebox it.
Apache Ivy is a .jar dependency manager, and it solves a lot of problems where we need several versions of one package for different functionalities. Without Ivy, you can get difficult to track errors if your .jars are called in an unexpected order.
And remember... there will always be "The technical TWer who likes to write their own and doesn't believe in anything."