AJAX Magazine: Howto integrate Google Calendar in your website using AJAX

AJAX Magazine: Howto integrate Google Calendar in your website using AJAX

AJAX Magazine: Howto integrate Google Calendar in your website using AJAX

AJAX Magazine: Howto integrate Google Calendar in your website using AJAX

Team Foundation Server [TFS]: Show Deleted Items in Team Explorer

great, i searched for it but I could not find it was needed :-( So what to do if we want to make an undelete on a deleted item???

so here it is:


Visual Studio -> Tools -> Options -> Option Window

Left Tree -> Source Control -> Visual Studio Team Foundation -> Below the proxy settings

:-) how cute :-) INDEXUS!!!

Finally I can make an undo delete on my files

Some discussions around of Daily Builds

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=862

Implementing Daily Build and Smoke Test

One important aspect of Daily Build is the word Daily. Steve McConnel mentions two similar metaphors for a Daily Build in his article about Daily Build and Smoke Test:

On the one hand, Jim McCarthy [*] compares the Daily Build with the beat of a heart. Once the heart does not beat any more, the project has died. From another point of view, the Daily Build is an integral part of a functional software project in this context: A project without Daily Build is nonviable.

On the other hand, Michael Cusumano and Richard W. Selby [**] think of Daily Build as
a synchronization pulse. Code fragments of different programmers are allowed to come a little bit out of sync between two pulses but after the next sync pulse, all parts of the project must fit together again.

The next point to think about is a useful broken build management. It is very important to find a good balance between a too weak and a too strict contract. Such a contract should contain all the show stoppers that really break our project but exclude uncritical defects that only interrupt the software building process while being no threat to our projects healthiness.

Next issue to address is the need for a matching Smoke Test. The best Daily Build is worthless without a good designed and balanced Smoke Test. Such a Smoke Test must not include all features of the whole system (which would be very difficult to test) but should comprise the major parts of it. So if this test fails, we will know that we are in trouble.

Another important point is to let the development team know about the importance of not breaking the Daily Build. Most teams do so by introducing a penalty for that developer who is responsible for the clash, like a small fee. That programmer should then work on the problem until it is solved.

Goal of this strategy is to let a breaking build be the exception, not the rule.
Last but not least it is important to continue using Daily Build in stressful times, too. Especially in such situations, the effort for the build process can seem useless but it isn’t. Stressed developers make more mistakes, quality is decreasing -

Daily Build is then more necessary than ever.

* Steve McConnell. Daily build and smoke test. IEEE Software: Best Practices, 13(4), July 1996.
** Michael Cusumano and Richard W. Selby. Microsofts secrets. The Free Press, 1995.

Daily Build with Smoke Test!

the 4 big BENEFITS of using Daily Build with Smoke Test:

1.
- minimized integration risk Daily Build and Smoke Test
- different team members combining code they have been working on separately
- different team members integrating code they have been working on separately
- The resulting composite code might not work well.
- Depending on how late in the project the incompatibility is discovered, debugging
might take longer than it would have if integration had occurred earlier,
program interfaces might have to be changed, or major parts of the
system might have to be redesigned and re-implemented.
- Integration errors have caused projects to be cancelled.
- The daily build and smoke test process keeps integration errors small
and manageable, and it prevents runaway integration problems.


2.
- reduces the risk of low quality.
- unknown project status without using a daily build and smoke test strategy
- High risk of integration and quality problems [hidden faults is high] -
they expensive, in case of manpower and amount of coffee you need to fix them!!!!

3.
- easier defect diagnosis by giving exact indications of what happens with
your test. If case the daily build of day no. 4 succeeded and the following
day failed .. then you know where you have to search!

4.
- improves the team morale, they know about their quality and know they
working with up-to-date processes, not processes which are already more
then 20 years old!!
- Developers they see daily build is building successfully its a Hugh
morale boost for them (ahoy us! )
- its nothing really exciting or so, but programmers, testers and all the
rest of your team can watch how the project is growing and growing and
every morning you have an actually status about it.

Note: Yes the first project is hard to setup, until you get all what you need and you have setup everything, but in the end the result of it is amazing -> take yourself the needed time to setup daily build as soon as you can even when your project contains 1000 LOC's its the right way in my point of view.

Daily Build - The Daily Build concept

The Daily Build concept is integrated in nearly every new Software Engineering approach.

Personally I think that its common to use a separated build server applying the continuous integration approach / strategy. Call it however you want but in my point of view its a must.

The build server is responsible to request automatically request all sources from repository and its common to do that in a iteration of once a day. So this server is responsible to extract all sources and to build them. Its also common to integrate all your Unit test into this build to verify the integration. Oh, you don't have unit test ... what a pity... You should maybe checkout where the payback is of the additional effort of unit testing.

to make a build is much more then to press just F5 or F10 in visual studio or your preferred development environment. but anyway there are enough other sources you can receive the information what a complete build means [or check out previous posts.]

Lets go back to the issue of daily build, or the daily build concept.

Goals of Daily Build
There are several goals of daily build, but lets write about the main goal of it.
The main goal of Daily Build process is to integrate a periodical integration of all your software pieces.

Why periodically and not whenever when I want... 3 things..

1. in every handy made process the possibility of failures are here and usually they also not reproducible.
2. you have a build server, let him do the work. When it fails once then it always fails.
3. normally there are more then just one person who is working on sources.

The mention third point is very basically and can happen all the time. Just let the build process fail, which is really a bad problem for the project manager. If that happens, he or she has to locate the problem and solve it - or, even better, let the responsible programmers search for the problem in their code.

So, a developer has to write a few test cases which ensure the correct behavior of the main features or methods of his components. Which will be tested automatically every single night, and in the morning you get your report with all needed information why your daily build today failed ( or not failed ).

javascript code

Great Java Script Code snippets.

javascript code

Ajaxload - Ajax loading gif generator

Great Idea, simple and very usefull :-)

Ajaxload - Ajax loading gif generator



a sample page is available at:

Loading.htm