I’m tracking current project state using automated test suite that is executed 24/7. It gives information about stability by randomly exploring project state space. Test launches are based on fresh builds from auto-build system connected to master branch for this project.
Recently I hit few times typical stability regression scenario: N+1th commit that should not have unexpected side effects caused crash in auto-testing suite just after 2 minutes of random testing thus blocking full test suite to be executed. OK, we finally had feedback (from auto-test), but let’s compute the (bug .. detection) delay here:
- auto-build phase: 30 minutes .. 1 hour (we build few branches in cycle, sometimes build can wait long time to be performed especially if build cache has to be refilled for some reason)
- test queue wait phase: 30 minutes (pending tests should be finished before loading new version)
- review of testing results (currently manual): ~1 hour (we send automatic reports, but only twice a day)
(more…)
Everyone agrees that internal state checking using assert(), Q_ASSERT(), assert are good. Programmer can declare expected input (asserting parameters), internal state (invariants) and verify return values (postconditions) and runtime will verify such expectations. There are languages with direct support for assertions in those three variants (Eiffel with his Design By Contract philosophy).
Those assertions typically will show filename/line number/message information and abort program / raise an exception if the condition is not met. Runtime environment then can collect current stacktrace to give developer more information on failed expectation.
One can disable assertions entirely (C++, Java) or select subset of assertions (Eiffel) for production releases. Resulting code will be faster, but failed expectations will not be verified by software – problem reports may be harder to interpret.
On the other hand if an assertion is too strict (the assumption may be invalid) it may abort program giving user negative impression about software stability.
What to do then? How can we keep problem-diagnosing power of enabled assertions and prevent minor of invalid failed assertions from aborting whole program?
The answer is: weak assertions (assertion without abort).
(more…)
After making decision to launch online booking service for existing calendars (Google / Microsoft Exchange) it’s time to make minimal functionality specification. Then landing page will be prepared to check if the subject catch attendance then MVP to prove basic flows will work as expected.
Glossary:
- Customer: calendar owner
- Client: wants to book an appointment with customer
- Time slot: period of time that can be selected for appointment
MVP Use case list below (will define implementation order and priorities):
- Show customer’s calendar on a website with available slots
- WHY: Proves that we can read existing event source
- Allow to book an appointment for selected slot
- WHY: Proves that we can write existing event source
- Allow customer to register new calendar
- WHY: Allow for external tests for potential customers
- Allows to set timezone, day of week range, hours range
Optional use case list:
(more…)
Would you like how your web application performance behaves across longer time periods? Now it’s possible with site-uptime.net! We’ve just added visualisation of statistics:
Above sample is not bad system responded in <1s for >88%. It looks like no optimisations needed here. Let’s see different case:
(more…)
Today I moved using site-uptime.net development from Bazaar repository to GIT using elegant bzr2git script. The why:
- In-place branches (I used to use them heavily)
- Faster (no Python libs loading during “cold” start)
- Can’t live without “git rebase -i” now
