+1: If you're within cities, it generally doesn't matter, which network you use. I've learnt that Vodafone and T-Mobile are the more expensive solutions and generally like to sell you sim-locked devices.
I'm quite happy with a cheapo-solution, using a (non-sim-lock) stick and prepaid plan from "Aldi", one of the nation wide supermarket chains. Stick: ~50€, monthly flatrate: ~15€ (careful: if you've got enough money prepaid and not cancelled the monthly flatrate, it's automatically continued the next month) or ~2 or 3 € per day. They say to limit the speed from 5GB (monthly) or 1GB (daily) on. This is a resold "E-Plus" network access.
Windows "wizard" software is provided on the stick. Access also works well with Ubuntu "Karmic Koala" (without the windows software, of course).
Thanks for pointing this out. Actually NEST is based on BEAM, which is currently in version 4.5 (this tool is the first one referenced on the esa page you linked)
If you are able to read german (or your coworkers are) - Frank Westphal has already written a good comparison for JUnit 3.8 and 4.0 at http://www.frankwestphal.de/JUnit4.0.html. You might want to try this.
It's huge, but reasonably quick on a non-ancient computer. Incremental compiler helps keeping the perceived performance up. Code completion, Refactoring support and quick fixes are way better than anybody using textpad, emacs or vi could ever imagine. Getting used to this makes you wonder how you could ever be productive without. Try IntelliJ Idea if you don't want to try eclipse (but idea is commercial).
I've had your experience with an older IBM Websphere Developer version, based on an older eclipse, but eclipse had a reasonably good performance since I first tried it. Keep in mind that it offers a lot more than just a text editor.
I don't see TestFirst as a Test Strategy, but as a design technique. Writing Tests first forces you to think differently about what you want to write.
This forces you to write testable code - writing tests afterwards does not force you to do that.
Of course, having the tests available later proves valuable for testing your application, but the tests main purpose is to lead you to a testable design
You'll most likely experience severe difficulties in adding Unit Tests to previously untested code. It might be easier to add acceptance tests (e.g. high-level scripts that utilize the application), especially if you want to cover more than small partitions of the application quickly
From that site:
The Microsoft Windows Security Update CD includes Microsoft critical updates released through October 2003 and information to help you protect your PC. In addition, you will also receive free antivirus and firewall trial software!
According to Bugzilla entry 28327 this does not seem to block every traffic:
A year ago I found, that css stylesheets will still be loaded from remote locations. This bug must be one of the longest-open entries in bugzilla.
Use "View/Message-Body As/Plain Text" to be really sure to cause no hit anywhere.
I am working as software developer with a preference for what has become hype as "agile programming". In Extreme Programming one of the techniques was called "40 hour week" and is now called "sustainable pace". (see reference, more techniques on same site)
Along with several other techniques from agile processes I have cut down my stress level by clearly communicating that I will manage to finish exactly those tasks that I finish, no more, nothing less.
Therefor I welcome external priorities for the work I'll have to do (as the tasks are also defined by our customers, this is not too much to ask for).
Baseline: For any 25 Tasks, do not accept less than 25 levels of priority. Demand that your customer/boss/whoever sets these priorities for you. After all, you will work through them in an order, and if you happen to have too many tasks for a given time, you'd better have the important ones done when time is over.
Another tip is to use strict timeboxing. It helps a lot to know that you are currently sprinting towards your goal. It does not help, if the goal moves shortly before you reach it. Accept new tasks only for the next timebox/sprint, but never allow stretching a timebox (which may be a week, a month or anything in between).
Hi,
if you don't like the complexities and/or prices or installation hazzles of "the big" OLAP enabled servers, try instantOLAP with a low footprint and easy web access to your data.
This is "low footprint" in terms of installation issues and requirements for backend databases: The engine enables you to talk OLAP to any relational database without first needing to create cubes in your dedicated OLAP server. This way you can issue OLAP queries to your production database instead of the one month old cube.
Others have already commented on their varying mileage
with this topic, I too believe that TDD (done correct)
will rather save time than cost more time. At least in
the long run. (I'll leave the "done correct" part to
somebody else, books and articles have been recommended
in other comments).
There's one misconception that I always see with TDD
and Unittesting: Both are not the same.
In my eyes, TDD is rather a design strategy than a
testing strategy. It certainly gives a test suite
as a very nice "byproduct", but first and foremost it
forces you to think about what your code is supposed to
do and write it down. Usually TDD code looks completely
different from non-TDD code.
So you'll have to add some portion of time taken for
upfront design to the time you take to write code in
order to compare writing testdriven with non-testdriven
code.
This doesn't mean, that the statement commented was wrong:
I also believe that you have to manage some more or
less steep learning curve in order to be able to really do
testdriven development, just as you have to learn a lot
about each process, language or framework you work with.
I'd certainly be quicker writing a small java tool than
writing equivalent five lines of PERL because I've never
really (wanted to) manage the PERL learning curve.
Regarding web applications: I believe it's always good to support multiple browsers - even if you don't need to because you write applications for a closed user groups, that uses only a known browser.
As soon as you start to automatically test your web applications with scripts (e.g. HttpUnit) there is suddenly another browser: The test script. The more browsers you support from the beginning, the higher the chance that you can easily automate tests for your application.
Your mileage may vary with read-only sites, but others have already elaborated about this.
I've made best experience with this technique. Whoever asks me to do anything (usually this is a small number (~5) of different people) I ask back for the priority of the job.
If there's 50 tasks I'm pesting them for 50 different priorities, not just 3. Everybody understands that I can't do more than one thing at a time, everybody seems thankful that they can set priorities and don't rely on my priorities.
From time to time (if I believe something doesn't fit or someone misuses this power) I check back with my boss, but usually this is not necessary.
Another hint would be: Don't keep backlogs. Accept work for a month, not more. Nobody (especially not you) is happy to see that a task will be performed in a year. (and when the year is over it will be another year, because so many new tasks came up). When the month is over, get more work. Some recommended reading on this topic comes from xprogramming.com:
http://www.xprogramming.com/xpmag/PetitionTheKing. htm
Slashdot Mirror
+1: If you're within cities, it generally doesn't matter, which network you use. I've learnt that Vodafone and T-Mobile are the more expensive solutions and generally like to sell you sim-locked devices.
I'm quite happy with a cheapo-solution, using a (non-sim-lock) stick and prepaid plan from "Aldi", one of the nation wide supermarket chains. Stick: ~50€, monthly flatrate: ~15€ (careful: if you've got enough money prepaid and not cancelled the monthly flatrate, it's automatically continued the next month) or ~2 or 3 € per day. They say to limit the speed from 5GB (monthly) or 1GB (daily) on. This is a resold "E-Plus" network access.
Windows "wizard" software is provided on the stick. Access also works well with Ubuntu "Karmic Koala" (without the windows software, of course).
Thanks for pointing this out. Actually NEST is based on BEAM, which is currently in version 4.5 (this tool is the first one referenced on the esa page you linked)
If you are able to read german (or your coworkers are) - Frank Westphal has already written a good comparison for JUnit 3.8 and 4.0 at http://www.frankwestphal.de/JUnit4.0.html. You might want to try this.
It's huge, but reasonably quick on a non-ancient computer. Incremental compiler helps keeping the perceived performance up. Code completion, Refactoring support and quick fixes are way better than anybody using textpad, emacs or vi could ever imagine. Getting used to this makes you wonder how you could ever be productive without. Try IntelliJ Idea if you don't want to try eclipse (but idea is commercial).
I've had your experience with an older IBM Websphere Developer version, based on an older eclipse, but eclipse had a reasonably good performance since I first tried it. Keep in mind that it offers a lot more than just a text editor.
probably the subscribers, rushing and /.ing early...
And only because of the T-Name. Deutsche Telekom "T-Com" (german previously state-owned telecom company) will most likely sue them.
Hopefully they don't use magenta in their official announcement. :-)
(Caution, links in german language)I don't see TestFirst as a Test Strategy, but as a design technique. Writing Tests first forces you to think differently about what you want to write.
This forces you to write testable code - writing tests afterwards does not force you to do that.
Of course, having the tests available later proves valuable for testing your application, but the tests main purpose is to lead you to a testable design
You'll most likely experience severe difficulties in adding Unit Tests to previously untested code. It might be easier to add acceptance tests (e.g. high-level scripts that utilize the application), especially if you want to cover more than small partitions of the application quickly
From that site:
The Microsoft Windows Security Update CD includes Microsoft critical updates released through October 2003 and information to help you protect your PC. In addition, you will also receive free antivirus and firewall trial software!
According to Bugzilla entry 28327 this does not seem to block every traffic: A year ago I found, that css stylesheets will still be loaded from remote locations. This bug must be one of the longest-open entries in bugzilla.
Use "View/Message-Body As/Plain Text" to be really sure to cause no hit anywhere.
Along with several other techniques from agile processes I have cut down my stress level by clearly communicating that I will manage to finish exactly those tasks that I finish, no more, nothing less.
Therefor I welcome external priorities for the work I'll have to do (as the tasks are also defined by our customers, this is not too much to ask for).
Baseline: For any 25 Tasks, do not accept less than 25 levels of priority. Demand that your customer/boss/whoever sets these priorities for you. After all, you will work through them in an order, and if you happen to have too many tasks for a given time, you'd better have the important ones done when time is over.
Another tip is to use strict timeboxing. It helps a lot to know that you are currently sprinting towards your goal. It does not help, if the goal moves shortly before you reach it. Accept new tasks only for the next timebox/sprint, but never allow stretching a timebox (which may be a week, a month or anything in between).
See OpenSTA, an Open Source load testing application for web applications, with some more links in the WebLink section on portal.opensta.org
Hi, if you don't like the complexities and/or prices or installation hazzles of "the big" OLAP enabled servers, try instantOLAP with a low footprint and easy web access to your data.
This is "low footprint" in terms of installation issues and requirements for backend databases: The engine enables you to talk OLAP to any relational database without first needing to create cubes in your dedicated OLAP server. This way you can issue OLAP queries to your production database instead of the one month old cube.
Others have already commented on their varying mileage with this topic, I too believe that TDD (done correct) will rather save time than cost more time. At least in the long run. (I'll leave the "done correct" part to somebody else, books and articles have been recommended in other comments).
There's one misconception that I always see with TDD and Unittesting: Both are not the same.
In my eyes, TDD is rather a design strategy than a testing strategy. It certainly gives a test suite as a very nice "byproduct", but first and foremost it forces you to think about what your code is supposed to do and write it down. Usually TDD code looks completely different from non-TDD code.
So you'll have to add some portion of time taken for upfront design to the time you take to write code in order to compare writing testdriven with non-testdriven code.
This doesn't mean, that the statement commented was wrong: I also believe that you have to manage some more or less steep learning curve in order to be able to really do testdriven development, just as you have to learn a lot about each process, language or framework you work with. I'd certainly be quicker writing a small java tool than writing equivalent five lines of PERL because I've never really (wanted to) manage the PERL learning curve.
Regarding web applications: I believe it's always good to support multiple browsers - even if you don't need to because you write applications for a closed user groups, that uses only a known browser.
As soon as you start to automatically test your web applications with scripts (e.g. HttpUnit) there is suddenly another browser: The test script. The more browsers you support from the beginning, the higher the chance that you can easily automate tests for your application.
Your mileage may vary with read-only sites, but others have already elaborated about this.
More options came in August, when the gcj team announced to compile/run eclipse natively without a vm and much better startup time.
Olaf
I've made best experience with this technique. Whoever asks me to do anything (usually this is a small number (~5) of different people) I ask back for the priority of the job.
If there's 50 tasks I'm pesting them for 50 different priorities, not just 3. Everybody understands that I can't do more than one thing at a time, everybody seems thankful that they can set priorities and don't rely on my priorities.
From time to time (if I believe something doesn't fit or someone misuses this power) I check back with my boss, but usually this is not necessary.
Another hint would be: Don't keep backlogs. Accept work for a month, not more. Nobody (especially not you) is happy to see that a task will be performed in a year. (and when the year is over it will be another year, because so many new tasks came up). When the month is over, get more work. Some recommended reading on this topic comes from xprogramming.com: http://www.xprogramming.com/xpmag/PetitionTheKing. htm
Good Luck.Olaf