Shimon Krokhmal's blog

I have finally started to build a CI server for our project.
during the process, i've examined several build tools and CI servers, such as: CruiseControl\CroiseControl.Net, Ant\nAnt and MSBuild.
these tools have proven themselves enough (just google it..), but one thing similar to all of them was the huge amount of XML configurations that needed to be done in order to get you started.
after a short chat with Nati Dobkin on the subject, he suggested the TeamCity application, this is really a smooth start for the CI, a very modular & user freindly system that allows you to do what you need in the shortest way.

What am i talking about you ask ?
how does the rabit hole got to do with all of this ?

after setting up the environmet, i've started to try get this work with our project.
at first glance, this task should be easy : get the source from TFS, compile, create deployment files, deploy the files.

Q: what do you think will happen if you take your solution to an isolated environment and try to compile it?

A: if project was conducted badly, you'll probably get missing reference errors.
it even get more intresting if those missing Dll's reside in a different workspace(in the TFS), and the only thing that links this project to the other dll's is the physical path ON YOUR HARD DRIVE.
not exactly the right way to go.

Possible solutions:

• preserve the physical link and hold your breath that nothing bad ever happen
• make some order in the TFS server
• create a different solution for each Application\server in the system.

what do you think is the best way to go?
leave a comment.

as we described, The narrative should include a role, a feature and a benefit

“As a [role]
I want [feature]
so that [benefit]”

This template has a number of advantages.
By specifying the role within the narrative, you know who to talk to about the feature.
By specifying the benefit, you cause the story writer to consider why they want a feature.
It gets interesting if you find the feature won’t actually deliver the benefit attributed to it.
This usually means you have a missing story.
if there is one story with the current feature, which delivers a different benefit (and is therefore still useful), then there is a hidden story whereby you will need a different feature to deliver the benefit described.

The scenario title should say what’s different- You should be able to line up the scenarios side by side, and describe how they differ using only the title. It should be obvious from the title whether this is the scenario you care about, compared to the others.

The scenario should be described in terms of Givens, Events and Outcomes
This is the single most powerful behavioral shift in the adopting BDD process.
Simply by getting the business users, the analysts, the testers and the developers to adopt this vocabulary of “given/when/then”, they discover that a world of ambiguity falls away.
Not all scenarios are this simple.
Some are best represented as a sequence of events, described as:

given [some context]
 when [I do something]
then [this happens]
when [I do another thing]
then [this new thing happens]

And so on.

An example is a wizard-style website, where you step through a sequence of screens to build up a complex data model.
It is perfectly appropriate to intermingle sequences of events and outcomes, as long as you get into the habit of thinking in these terms.
One interesting emergent behavior is that the quality of the conversation changes.
You will quickly discover that you have missed out an assumed given, or forgotten to verify an outcome.
By introducing the given/when/then vocabulary, we can dramatically improve the quality of the group interaction.

The givens should define all of, and no more than, the required context:
Any additional givens are distracting, which makes it hard for someone looking at the story for the first time – whether from the technical or business side – to understand what they need to know.
Similarly any missing givens are really assumptions. If you can get a different outcome from the givens provided, then there must be something missing.

The event should describe the feature :
The event itself should be very simple, typically only a single call into the production code. As discussed above, some scenarios are more complicated than this, but mostly the scenarios for a story will revolve around a single event. They will differ only in the context (the givens) and the corresponding expected outcomes.

The story should be small enough to fit in an iteration :
There are no hard and fast rules about how you do this, as long as you break it down into demonstrable chunks.
In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together.
 

When we need to understand what a computer system is supposed to do so that it can best serve some business need, questions like:
• What is the most important thing the system should do?
• What is the next most important thing the system doesn't yet do?
• If we were to switch off the system, where and what would be the biggest impact?

These Powerful questions can be tough to answer.
But following these will guide us to insights that we hadn't though of.

the Acceptance Criteria consist of a collection of Scenario allow us to determine when we are done, The most important aspect of a story is the language in which it is written.
The golden rule is that the Story should be written in the language of the Role, that is to say the beneficiary of the feature.
If the Story represents a business feature, it should be written in business terms with the aid of a business analyst.
If the story describes a technical requirement, such as resilience or scalability (sometimes called “non-functional” requirements), it should be presented in the appropriate technical language.
Acceptance Criteria specify, as a collection of Scenario, what needs to be achieved if the Behavior of the Feature is to be considered finished.

A Scenario:
Some Behavior that can be automatically verified once the Story (or some part of it) is delivered.
The Scenario sets up the world in a known state (or in a way that will behave deterministically) and executes a sequence of one or more Events resulting in one or more verifiable Outcomes.
We commonly implement these scenarios, as FIT fixtures, Selenium tests or programmatically as code, but the technology is less important than the concept here, the aim of these verifiable scenarios is to define what a successful outcome looks like.

This use of Scenarios gives us two immediate returns.

• They form the basis for our estimates, leading to more consistent estimates than story-level estimations.
• They show when a story is trying to do “too much”.
  If there are more than a handful of scenarios (five or six), it suggests that the story should be split into several smaller stories, each providing independent benefit, and each consisting of a subset of the scenarios.
  Boundary or exception cases are good examples of this: sets of boundary scenarios might clump together to describe common business cases, and some of these clusters will be deemed more important than others. Smaller stories means finer-grained control over prioritization, finer grained visibility of progress and reduced exposure to technical risk.

Scenario structure:

Scenario 1: Title
Given [context]
And [some more context]…
When  [event]
Then  [outcome]
And [another outcome]…

the nerrative Gives us a brief description of what to deliver,
and why we should deliver it (in the form of Features and Benefits).

we shall define few terms:

A Role:
Is an aspect that describes the person, or thing, that will benefit from the Feature.
It is essentially the same as an Actor in a UseCase.

A Feature:
It describes something that the system should do (the behavior, as it were).
An important aspect of a Feature is that it is described solely in business terms and not in terms of technology or technologists,
unless of course the business is technology or technologists!!

A Benefit:
This is the reason we are delivering a particular Feature– it describes the business value accrued from this Feature.
Initially the Benefit is usually qualitative,
but we usually expect to see some quantitative business value assigned to the Story before it is chosen for development.
This is to help keep us honest and to ensure that we are focusing our development efforts on Features that have real business value.

To ensure that we don't forget any of these critical components we often use a template for the narrative like this:

As a <Role>
I want <Feature>
So that <Benefit>

A concrete example may be something like:

As a Developer
I want to be able to rename classes
So that I don’t spend too much time worrying about getting the name right first time

The reason for this degree of formality is that it helps us avoid some common analysis anti-patterns.

Two in particular are worth mentioning: 

• Feature = Benefit.
  This is where the “benefit” is simply a restatement of the feature, this is a common failing in technical or semi-technical customers,
  who wish to promote a particular technical solution.
  These requirements can often be (diplomatically) eliminated, reducing complexity, risk and the associated cost.
• Feature ≠> Benefit. (“Feature does not imply benefit”)
  The feature described will not deliver the benefit described.
  When this occurs it often reveals hidden requirements.
  It may be that the Feature delivers a completely different benefit which we hadn't identified.
  Conversely, we may need to introduce some new Feature to actually achieve the specified Benefit,
  a previously hidden, and thus unplanned, feature.

 

 

 

if you haven't read the introduction yet, please read the introduction to BDD

What is this story all about ?
The idea is that the words you use influence the way you think about something.
To smooth its path through the development process, We say that it must fulfill certain additional criteria.

A story should have a Title, a Narrative and AcceptanceCriteria:

Title:

Gives us a label to describe this piece of function throughout the life of the project.
It is important to choose good titles to describe the story,
Since the story is an atom of development and as such is referred to in all sorts of conversations throughout the life of the project.

Poor titles for stories are things like: 
   • Implement Performance Enhancements 
   • Move Data 
   • Create Persistence Layer

Titles should describe the story in business terms, and should make sense when,
For example, considered as a unit of value for the system.

Some examples of better titles may be: 
   • Accept Credit Card Payment 
   • Confirm Exchange Rate 
   • Accept Product Updates

As a part of our performance enhancements in our system, we disovered that we have 43 requests to the server when the page is loaded.
This is huge delay in page loading.

what he decided to do is recreate the images on the site into 1 big image & "pick" from it using CSS Sprite.

For those who does not femilier with the "sprite way", it is a concept that we take all our images and merge them into one combined image.
hence eliminating the need of requesting each image individualy.
using CSS classes we define the original images from the big image (sort of cutting it from the big image).

Doing this, it reduces the requests dramaticly and improves loading time of the page.
same outcome, better performance.

i'm making some cool Linq presentation for my upcoming lecture in 888.
when installing visual studio 2008 and sql server 2005,
a funny error came accross when i tried to connect to the SQL server through the visual studio(on vista):

Could not open connection to SQL Server - Named Pipes Provider, error 40

a few configuration modifications need to be done in the sql server server surface area such as enabling the named pipes, and granting admin priviliges to the worker user.

the second(and most important) is on the server name field you need to specify the sql server instance (for the connection string).

Enjoy.

 

it's going to be an off topic post,
so if you are seeking for some cool code topics & examples, this is not the post fo you...

lately i found myself surrounded with overdozed hardware and rigs,
i currentlly own :

1 workstation
1 HTPC
1 downloads server
1 laptop
1 Huge CRT
1 Huge LCD.
1 KVM switch
1 Router
6564536 Wires (Help ?)

Ok, this is alot of hardware, do i really need all of this ?
so, what am i planning to do ?

1. get rid of the HTPC rig, and the CRT screen (a new computer for my mom...)
2. convert the workstation to an HTPC (this includes some minor hardware changes)
3. work mainly from my cool new laptop
4. work wireless as possible to get rid of these nasty wires.
5. install all the rigs with proper hardware

this is lots of work to be done.....

 

I've created an israelli bloggers group on facebook.
if you have a blog and you are from israel, send me a request to join the group :)

Months after shani tagged me for this issue, it's time to pick up the glove, and write a post about it.

a little note on that matter,
i think that if a developer whats to become better, he should aknowelange it mentally to always strive for self improvement.

Things I should do.
to answer that question, i must ask myself what are my goals, where do i see myself in 3-5 years ?
well, as far as i remmember myself, my goal was always to become a solution Architect, the dude that can design "dreams" to reality.
to achive that, you must work your way from the buttom, get femilier with all the bits and bites, design practices, practice software development and after few years in the field, emerge your own opinion about software development process, devolopment methodoligies, and create new consepts.
once you have done all that, you can start becoming an architect.
after defining that, lets ask this question again :
What things should i do?

• read alot about development methodologies, and when/where to apply them (Scrum like development is not always suitable for every organization)
• upgrade my skills to current technologies (.Net 3.5)
• Apply new learnt stuff to daily tasks

Things I want to do

• Write a book on software development (it won't be published in the next year)
• create a perfect development process (is it possible ?)
• enter the BDD world.
  

Things I won't do
as much as it is tempting to leave what i am doing now, and persue my dream becoming a solution architect,
the next few years seems as a good time to gain more expirience at the development section before advancing to the next level.

Tagging this dude :
 Micky Shriber