Husk fra sidst

• Abstract classes kan ikke blive instantieret, og kan indeholde abstract methods
• Final classes kan ikke nedarves fra
• Final methods kan ikke overskrives

Overblik (for ugen)

• Containers
  • Designe en container
  • Generic types
• Introduktion til Collection framework
  • Collection<T> og List<T>
  • Generelle implementationer af disse
• Loops og iteration
• Arrays
• Implementering af array-baserede collections

Containers

Når man programmerer skal man ofte bruge en collection af objekter. F.eks. indeholder en pokerhånd et antal kort, et objekt der repræsenterer et kursus på universitetet indeholder en liste over de studerende der er tilmeldt osv. Vi har allerede arbejdet med lister i SML, men nu skal vi føre begrebet videre.

Vi bruger Containers til at holde styr på sådanne collections. (I java bruger biblioteket termet Collection,  men det er fordi Container var brugt til noget med GUI’en allerede). Basale containeroperationer inkluderer:

• Tilføje et element
• Fjerne et element
• Checke om et element er i containeren
• Udføre en operation på hvert element i containeren (tænk map og fold fra SML)

Containere er homogene. Dvs. at alle elementer i en container har samme type (ligesom lister i SML).

Eksempler på containere kan være:

• En mængde – Vi husker hvordan vi lavede en set signatur i ML, og hvordan vi implementerede denne. En mængde er en container uden duplicates – altså ingen elementer i mængden er ens.
• En Liste – Indeholder et endeligt antal elementer i en bestemt rækkefølge. Det giver altså mening at snakke om det første element, det andet element, osv.

Hvis vi skulle implementere en liste for studerende-objekter – hvad skulle den så kunne? Vi kan starte med de basale operationer fra før:

public void add (Student student)
   Add the specified Student to the end of this list.

public void remove (Student student)
   Remove the first occurrence of the specified Student from this list.
   Has no effect if the Student is not on this list.

public boolean contains (Student student)
   This list contains the specified Student.

public int size ()
   Number of elements in this list.

Vi vil også gerne kunne udføre en operation på alle elementerne. Til dette vil vi implementere en måde at trække student nummer n ud fra listen. Vi skal se senere hvorfor det er smartere end at lave en map funktion.

public Student get (int index)
   The Student at with the specified index.
   require: 0 <= index && index < this.size() //0-indexed

public void set (int index, Student student)
   Replace the element at the specified position with the specified Student.
   require: 0 <= index && index < this.size()

Vi kan nu lave en ny, tom liste:

StudentList roll = new StudentList();

Vi kan fylde elementer ind i listen:

roll.add(new Student("Bill",...));

Vi kan spørge om listens størrelse, og vi kan bede om student nummer n. Specifikt kan vi (hvis FinalGrade() er en funktion i Student) spørge om studerende nummer n’s final grade:

int iGrade = roll.get(n).FinalGrade();

Hvis vi nu skulle lave en liste der kunne indeholde PlayingCard objekter i stedet for Student objekter, så ville vi sikkert lave præcist samme liste bare med andre typer. Dette er absolut ikke optimalt. Det betyder at vi laver linje op og linje ned af duplikeret kode, hvilket er tåbeligt.

Vi tænker nu at vi kunne bruge en abstract class (som vi jo lige har lært om) til at implementere en generel liste, og så kunne vi nedarve de forskellige andre typer af lister. Dette er imidlertid meget besværligt. Hvordan skal vi f.eks. lave add og remove i den abstrakte klasse? Den eneste mulighed vi har er at bruger Object (som alle klasser nedarver fra) i vores abstrakte klasse og så kan vi typecaste elementerne i vores nedarvede lister.

Det ville imidlertid betyder, at vores preconditions vil blive styrket i vores nedarvede typer (den nedarvede type vil kræve et element af typen Student mens den abstrakte klasse bare skal bruge et Object.)

Generics

Heldigvis kom der i java 5.0 noget vi har haft i lang tid i c++ nemlig generics. Der findes således en klasse:

public class List<Element> { ...

Det betyder, at vi kan erklære vores pokerhånd og studentlist således:

List<Student> roll = new List<Student>();
List<PlayingCard> hand = new List<PlayingCard>();

Typen vi specificerer kan dog ikke være en primitiv type (int, boolean, osv.). Da skal vi bruge de wrapper classes der hører til (Integer, osv.).

abstraction for structuring implementation

Den måde de forskellige collections er implementeret giver et rigtigt godt eksempel på hvordan man skal bruge abstraction.

Interfaces bliver brugt som klientens udgangspunkt. Her kan man se hvilke metoder der er, og hvad deres pre- og postconditions er. Generel dokumentation. Eksempel: Collection<Element>, List<Element>

Abstract classes er skelettet for implementeringen. Abstract classes definerer “standard” metoder, som de klasser der nedarver kan gå ud fra. Eksempel: AbstractCollection<Element>, AbstractList<Element>

Concrete classes er den egentlige implementation. Eksempel: ArrayList<Element>, LinkedList<Element>

Herunder ses et billede af alle de interfaces der er i hele collection frameworket:

Og herunder er de forskellige implementationer og deres tilhørende interface(s)

Iteration

Vi kan huske hvordan vi valgte at lave get og set funktioner i stedet for at implementere en funktion som map eller fold. Dette er fordi i modsætning til SML, så er Java et iterativt sprog og vi kan have løkker. Vi har allerede set While løkken og med den kunne vi f.eks. gøre følgende:

int i = 0;
while (i < list.size())
{
   do something to List.get(i);
   ++i;
}

På den måde kan vi gå alle elementerne i en liste igennem. Vi kan f.eks. beregne gennemsnittet af nogle studerendes karakterer:

public double finalAverage(List<Student> students)
{
   int i = sum = 0;
   int length = students.size();

   while (i<length)
   {
      sum += students.get(i).finalExam();
      ++i;
   }
   return (double)sum / (double)length;
}

Det er dog en lidt kluntet måde at skrive det på med while loops. Vi bruger derfor en for løkke der kan gøre det hele nemmere for os. En for løkke virker på følgende måde:

for (initialization statement; condition; update statement)
{
   body;
}

I forhold til while:

initialization statement;
while (condition)
{
   body;
   update statement;
}

f.eks:

for (int i=0; i < list.size(); ++i)
   do stuff to list.get(i);

Der findes også en for each ligesom i php, men jeg synes det er noget fis og gider ikke skrive om den

Just about all developers work by iterating in one way or another.

The biggest problem isn’t that you have to change things that are already done, or even throw it away. The biggest issue is that it takes time, and time is pretty much always more precious than money. That’s why the designer can save a lot of time by iterating in the pre-development phase, so he doesn’t waste the whole team’s time.

Iteration means the act of repeating and it’s what we do to make really good games. We make something, look at it and then we notice what we can change to make it better, or maybe even something that doesn’t work as intended at all and “must” be fixed.

Doing this late in the development cycle can be tricky, hard and expensive, as it might require effort from very many team members from different disciplines. Of course, it depends on what you’re about to change. Some minor tweaking might not be a big deal.

Sure, people in the team might whine a bit when changes are to be made because they think that it’s either good enough as it is, the designer should have “known” about the result in advance or just because they don’t want to throw away work that’s already done, but leaving that aside, the biggest issue is time. You’re always working towards deadlines and time equals money.

That’s why it’s important for designers to iterate when only being in the pre-development and theoretical design. Write the design and then make sure that all design-ish people analyze it with a microscope and iterate, iterate and iterate!

That’s a great thing about prototypes as well. They’re built for you to be able to try out things in and make rapid changes. Use them! Unfortunately, not all projects use prototyping, which I think is a real shame. It doesn’t have to be a massive fully playable game.

Heck, it doesn’t even have to be digital.

A prototype can be anything that let you test anything, like a small, small element of a game mechanic, interaction design, or whatever. I think it’s worth dedicating and spending time on prototypes even if it “steals” time from the actual development, because in the end, you’ll save time and turn up with a better product.

Also, try and keep alert so you can make changes in good time, instead of waiting untill the last minute. The less work done to be changed/discarded, the better. And as a designer, dare to say that something doesn’t work right, instead of waiting for someone else to notice it. It doesn’t matter if you become the bitchy one because you’re always the one to point out the “bad” stuff.

Making games is just like making anything else. Let’s say you’re gonna draw a panda. If you draw a panda and you’ve never done that before, you’ll get a result. Now, afterwards, draw another one. Odds are that the second one will look better.

But in the end, you’ll run out of time and can’t iterate anymore. Except if you’re Blizzard, then you can iterative untill you’re satisfied and release globally loved games.

Because the time is limited, it’s important to make sure that iteration cost as little time as possible. That’s why it’s a good idea to start iterating from day one as a designer.

If I were to save this post as a draft, read it a couple of times and then re-write it, I’m 100% sure I would end up with a much better text.

1. Identify your users’ stories

As I studied users’ thoughts, I found patterns in what my project was really designed to do, above and beyond what the project brief said. I listened to what my mind was drawn to listen to. These were the users’ stories — what was most important in their working lives.

There are no right or wrong answers in listening. Be honest with your users that you’re there to add value to the way they work and their stories – needs, expectations, attitudes and capabilities – will become clear.

2. Embrace your users’ needs

Once I am aware of users’ needs, it is far easier to design according to them. When faced with a decision, I can compare it to their values by documentation as personas, and see it will bring me closer to a solution that is fit for them, rather than what is easiest for the project team to produce.

3. Accept expanding feature sets

A ZenAgile mind does not struggle. It accepts users’ needs as they truly are. A rock is a rock. It will remain that way no matter how much you worry, wish, or pressure it into changing. Worrying about requirements and ever expanding user wants are the same way. I accept requirements for what they are, do not waste time or energy fretting over it, and group them into feature sets for delivery in such a way that, as a whole, they add value to users’ work.

4. Energise for change

A ZenAgile mind can give you extra energy for change as you are not wasting energy fighting against the inevitable. As above, there is a large rock in your way. You have three options:

• run into the rock repeatedly
• agonize about the rock being in the way, or
• find a way around the rock.

Before ZenAgile, I chose the first two options. With ZenAgile, I now accept the rock for what it is: an obstacle. I accept that you cannot go through it. I do not panic, and waste time and energy worrying about the obstacle. Instead I make my own path around the obstacle, either over the rock, around the rock, or under the rock.

This is Seijaku (静寂) — the energised calm.

5. Enhance knowledge of yourself

As I practice ZenAgile, I spend a fair amount of time in conversation with others and thereby understanding myself and how I come to terms with change: change in the project context, changes in requirements, and changes that need to occur to the solution.

In time, I’ve learned to quiet my mind. I’ve listened to the same fears for projects repeating themselves which inspired me to change what was causing those fears. I’ve realised, for example, that lack of a user-centred approach was a large source of anxiety, and so it was time for a change. Without time to think and meditate on the conversations in a project, we tend to ignore what our mind is telling us, and remain locked into our old patterns of doing things.

6. Gain confidence in the agile way

As you reflect on your inner self, you become conscious of who you really are, your role, and the skills you bring to aspects of the agile project. You learn what makes you happy, what is beneficial to your project, and where you fit into the multidisciplinary team. You bypass the fears and anxieties of your mind, what role you play — Business Analyst, Project Manager, Information Architecture, User Experience Designer, Change Manager — and focus on doing what needs to be done. Boldly and passionately complete the iteration. The opinions of traditional organisations like PMI, IIBA, ABAA, etc, do not matter, because you know you are doing what is right.

7. Appreciate the iterative project lifecycle

I accept the project as it truly is – evolutionary in nature, rather than revolutionary. You will always uncover new aspects of users’ needs. You will always uncover the unknown as you proceed boldly through the project. Some will be surprises like a starry evening, a stroll by the river, or a night of solitude. Each will have their own unique characteristics to be appreciated. Mundane user needs also hold their own charm. Observing the quiet details of the project lends value to the less appealing aspects, and brings peace and joy in commonplace tasks.

8. Increase consideration for others

Each person on the project is interconnected. We are all searching for the solution, requirements, and a meaningful project to work on. It is much harder to be angry at the user who argues with you about scope when you realise they are on the same path, just at a different point in their journey.

9. Simplify your project and your documentation

Conversation not documentation helps you differentiate between needs and wants. To document things completely today is to suggest that it will fix users and their workplace in time until the project has been completed. By focussing, instead, on a minimalist, simple project solution delivered in a short period of time, with just enough documentation to describe the decisions made, you are able to deliver value to people now and then build upon that solution to meet their future needs.

This is Kanso (簡素) — simplicity and elimination of clutter from the project

10. Cultivate a giving spirit by mentoring others in the team

When you are doing your role in the best way you can, your heart fills with joy. You are doing what you were put on this earth to do, and doing it to the best of your ability. Your life is simple, you are living your values, and you have a clear mind. You can then give to others, mentoring and teaching with a loving spirit, to help them along their path.

This is the True Way of ZenAgile

M

I recently created a post on a BA’s role on agile projects. The essential message was, simply, that there is no BA role. There’s also no PM role either. However, both disciplines have an immense number of skills that are incredibly valuable in agile projects.

Sprint Zero

• Identifying users: Understanding who to talk to and who the prioritised feature sets and requirements represents if the first skill needed on an agile project. A BAs skills in stakeholder segmentation is the perfect starting point as is documenting them as personas.
• Collecting user needs described on story cards: BAs have a great number of skills in eliciting requirements. In Sprint Zero all that is required is documentation as a story card:”As a [role] I need to [activity] in order to [outcome]“This gives you great traceability throughout the project because everything as to tie into enabling the user to undertake the activity and give them the outcome they seek.

Articulating the skinny solution

• Prioritisation of requirements: What requirements are more important than others?  BAs have skills in negotiation, liaison, workshop organisation and execution. Pair a BA with an Information Architect (IA) or user-experience designer (UXD) and you get a good idea of the prioritisation of their needs and how they need to be articulated during the iteration phases as complete feature sets. Remember it’s not about having mandatory, desirable, etc. Instead, agile requirements are listed in priority order with a minimum set — the things we can’t do without — forming the skinny solution.This is where the BAs skills are essentially lacking because it’s more in the province of cognitive and behavioural psychology. The skinny system reflects users’ hygiene factors.Pair a BA with an IA, however, and the way to elicit the hygiene factors will become clear.

Planning an iteration

• Work estimation and benchmarking: What is the team going to produce? What skills are required? What activities will be done in this iteration? How long will elicitation and validation tasks take? These are all questions that BAs because of their ongoing involvement in projects are readily able to answer.I like to ensure that I’ve got a wiki handy to note the aspects of the estimation so that I can change the estimation into a benchmark once the work has been completed. Over time, this becomes a valuable knowledge tool because I can simply say “when we last did it, it took [this long]“
• Risk analysis: While doing work it’s the job of all team members to understand issues and risks as they arise and communicate them to the team’s leader, Sensei or Product Owner. The ability, therefore, to analyse on the fly is vital to the team and a skill that BAs have in spades.I find that differentiating between a fear and a risk is the hardest thing for peope to grasp. People often fear that something will eventuate, but when you start to boil things down into hard facts abouta) the impact the issue will have, and

  b) the actual likelihood of occurence (based on research) then fears can rapidly vanish when also paired with constant communication from standup meetings.

  In this way, the BAs skills are best applied in the Roshi, Scrum Master or Project Lead roles.

Understanding the context

• Elicitation and observation: Analysing how people work, why, and the outcomes achieved is an important part of a BAs skill set.  Whether done through interviews, focus groups or a contextual inquiry (my own favourite), understanding the context of use and communicating it is a BAs core strength in agile environments
• Communication: How do you relate to the rest of your multidisciplinary team that you know the context of use — both from a user and systems perspective? BAs have a variety of tools they use regularly coupled with a talent for customisation of communication mediums and messages so that information is passed on to others with maximum efficiency.So what are some of these tools?
  • Storyboards (which I love to draw!)
  • Plans on a page (epic stories)
  • User pathways
  • Behavioural and process flow diagrams
  • Context diagram
  • Logical data model

  Notice that these are all light-weight, can be done in a short period of time, are easily changed, and are, essentially, placholders for a conversation.

Understanding the human, strategic and system requirements

• Custodianship of requirements: Understanding context is one thing, but then drawing the relationships between context and the needs of different people, and then taking into consideration the constraints, is a BA’s bread and butter. Where other disciplines, particularly UXD, tend to have greater strength in understanding and documenting context, the BAs strength has always been in elicitation, translation and communication of requirements, and then the management of these requiremens through to solution design, validation and implementation.For people like me, who tend to like to work at the ‘big picture’, having a BA who is detail oriented is a must.

Solution design

• Translation, communication and business representation: This is my favourite part of the iteration. While other team members might be responsible for the organisation of information of a system, its interaction design, and its systems architectural design, the BAs skills best served during the design phase is in representation of business and end-users. This is largely because their role as custodian of requirements makes them the most familiar with what is required and what the outcomes need to be when putting everything together.

Validation of the solution

• Diplomacy, negotiation, and whole-of-project representation: While programmers use automated testing in agile environments one aspect that can’t be automatically tested is whether or not the system behaves in the way that matches the way users need and want to use the product. Here the BAs diplomacy is his most valuable asset to bring to the agile project. He has to balance the needs of everyone, as well as their expectations, to help negotiate an agreement that the solution works, or whether additional things need to be incorporated in order for the solution to be acceptable to those who will use it.Of course, the outcome also needs to be communicated to The Powers That Be. With their strong skills in diplomacy and negotiation, a BA is able to represent the team and project as its Roshi, Scrum Master, or Project Lead.Then there’s letting the team know they’ve not suceeded in producing a valid solution. Lots of people get very attached to what they think is the right way to proceed and having users tell you that it’s not what they want can be incredibly frustrating. It means that the BAs skills of diplomacy are not only valued as an outward facing ability but also as an inward facing one as well

Implementation

• Diplomacy and sign-off: Having completed the ISO13407 cycle final implementation the feature set needs to be signed-off. Someone has to remind users and the business of how the iteration has been conducted and the points of agreement throughout. This can be a delicate matter particularly given many users and sponsors want a big thick document to read at their leisure and then sign.I usually print and package all of the smaller deliverables and put them into a folder. The first page lists the milestones and activities, agreement dates and who was present/represented, and when agreement was reached. The bottom of the page has the dotted line on which to sign.
• Setting expectations: I’ve found other sponsors don’t care so much about being this formal, particularly given the BA has been in constant communication with them and set expectations along the entire feature set iteration.

Ultimately, while there is no actual BA role, a BAs skill sets are of incredible importance throughout an agile project. This is a breath of fresh air for those of us who are only invited by the PM to elicit requirements during the first stage of the a waterfall project only then to be brought back onto the scene to help with users acceptance testing. This, ultimately, is why as BAs, we should all be championing agile. And if you’re not, then you should be!

So where are your strengths? What skills do you use most often as a BA in agile environments?

M

I have my problems with iterative design. Personally, iterative design is the way to go for me. Professionally it’s my biggest enemy.

When designing games, I find it impossible to think of every (and I mean EVERY) little aspect of the game. I just can’t. Even harder is that I cannot always guarantee that my design is fun or that it “feels right” when played. Making a game feel right  is the hardest process, because it involves a lot of fiddeling around with animation, response times, feedback and so on. To really get those things nailed, iteration is the way to go – although time and budget restrains often keep me from iterating until I feel the game is good to go.

Now, those budget restrains are not what makes iteration my biggest enemy. It’s my co-workers. Don’t get me wrong here, they are great guys but every time I ask for iteration, it weakens my position as a Game Designer. It almost feels like I’m saying: “I’m a bad designer. I have no clue about what I’m doing. I can’t design on paper.” I had people come up to me and ask me, why I did not know this or that button had to be there 6 months ago. All I could answer was “I simply didn’t know back then!”. Well, that must mean I am a bad designer  - at least to the person asking it does.

Iteration feels like admitting that you don’t have a clue. If you’d have a clue, you could’ve designed everything in pre-production. At least that’s what a lot of people expect of me.

But I am content with this. Iteration IS the way to go. At least for me.

One of the most interesting parts of Agile project management is watching the velocity of a team increase over time. As a team works together their productivity tends to increase. Agile represents the amount of work a team produces in a metric called velocity. Frequently teams new to agile will size the work in a time based unit such as hours or days. This is a common carry over from traditional project management. While Agile does manage time and resources, the time is fixed not variable. In Agile an iteration or sprint is a fixed length of time typically between two or four weeks. A chart showing time spent working in an iteration isn’t that valuable. A better process is to view the amount of work a team can produce in a specific amount of time. This is called velocity.

One challenge managers have with velocity is attempting to plan work for a new team on a new project since the velocity of the team is not known. Typically the first couple iterations, a new team is still forming and learning how to work together. Over time the estimates and velocity will stabilize. Looking at the velocity of a team as measured in points rather that hours provides a better indication on the performance of the group. Once the velocity begins to stabilize a team can accurately plan the work for a particular iteration.

Lets look at an example. A small team is pulled together to work on a new project. They sit  down and estimated 30 stories varying between 2 and 10 points of effort each. The team believes they can take on 30 points in the first iteration (two weeks). At the end of that iteration the team only completed 10 points. When planning the next iteration the team learns from the previous one and only plans to complete 15 points. Iteration 2 hits the mark, the team does complete 15 points. For Iteration 3 the team plans for 15 points again. This time however they are able to complete 17 points, they’re getting better. Iteration 4 they plan for 18 points but produce 22. Iteration 5 they plan for 20 but only produce 18. Feeling they’ve identified the standard velocity at 20 points, the team continues through the project allocating 20 points per iteration. With this in mind the team can look at the work produced and determine how productive they are and forecast a valid completion timeline. This forecast is the projected project burn-up. The burn up chart shows the actual accumulated work completed against the projected values across multiple iterations. The burn-up chart can also chart scope increases and decreases A burn-down chart on the other hand deals with a fixed amount of work and shows the amount of that work completed in a single iteration. Both of these commonly used planning and status charts can’t be produced without understanding what the velocity of the team is. 

It’s tempting to use time as a unit of measurement in agile. Try to break away from the traditional views and track productivity instead. The results will be a more confident team and more accurate planning. In the end your customers will thank you for delivering what you said when you said, and for providing valuable statuses along the way.

Resources:

http://agilesoftwaredevelopment.com/blog/jackmilunsky/significance-story-points

http://www.versionone.com/Resources/Velocity.asp

http://grantjoung.blogspot.com/2009/07/efficiency-must-have-agile-metric-as.html

http://agilesoftwaredevelopment.com/blog/pbielicki/predicting-team-velocity-yesterday-weather-method

One of the most interesting parts of Agile project management is watching the velocity of a team increase over time. As a team works together their productivity tends to increase. Agile represents the amount of work a team produces in a metric called velocity. Frequently teams new to agile will size the work in a time based unit such as hours or days. This is a common carry over from traditional project management. While Agile does manage time and resources, the time is fixed not variable. In Agile an iteration or sprint is a fixed length of time typically between two or four weeks. A chart showing time spent working in an iteration isn’t that valuable. A better process is to view the amount of work a team can produce in a specific amount of time. This is called velocity.

One challenge managers have with velocity is attempting to plan work for a new team on a new project since the velocity of the team is not known. Typically the first couple iterations, a new team is still forming and learning how to work together. Over time the estimates and velocity will stabilize. Looking at the velocity of a team as measured in points rather that hours provides a better indication on the performance of the group. Once the velocity begins to stabilize a team can accurately plan the work for a particular iteration.

Lets look at an example. A small team is pulled together to work on a new project. They sit  down and estimated 30 stories varying between 2 and 10 points of effort each. The team believes they can take on 30 points in the first iteration (two weeks). At the end of that iteration the team only completed 10 points. When planning the next iteration the team learns from the previous one and only plans to complete 15 points. Iteration 2 hits the mark, the team does complete 15 points. For Iteration 3 the team plans for 15 points again. This time however they are able to complete 17 points, they’re getting better. Iteration 4 they plan for 18 points but produce 22. Iteration 5 they plan for 20 but only produce 18. Feeling they’ve identified the standard velocity at 20 points, the team continues through the project allocating 20 points per iteration. With this in mind the team can look at the work produced and determine how productive they are and forecast a valid completion timeline. This forecast is the projected project burn-up. The burn up chart shows the actual accumulated work completed against the projected values across multiple iterations. The burn-up chart can also chart scope increases and decreases A burn-down chart on the other hand deals with a fixed amount of work and shows the amount of that work completed in a single iteration. Both of these commonly used planning and status charts can’t be produced without understanding what the velocity of the team is. 

It’s tempting to use time as a unit of measurement in agile. Try to break away from the traditional views and track productivity instead. The results will be a more confident team and more accurate planning a reporting. In the end your customers will thank you for delivering what you said when you said, and for providing valuable statuses along the way.

Resources:

http://agilesoftwaredevelopment.com/blog/jackmilunsky/significance-story-points

http://www.versionone.com/Resources/Velocity.asp

http://grantjoung.blogspot.com/2009/07/efficiency-must-have-agile-metric-as.html

http://agilesoftwaredevelopment.com/blog/pbielicki/predicting-team-velocity-yesterday-weather-method

Alle Beobachtung ist immer an Sinngebrauch geknüpft. Deshalb kann man sinnlose Beobachtung ausschließen. Beobachtung kann nicht vorgestellt werden ohne Rekurs auf Sinn.

Hinzufügt werden sollte noch, dass auch die Möglichkeit der operativen Rekonstruktion der Sinnform gibt, also Betrachtungen darüber, wie ein System durch Iteration, Varietät und Redundanz Sinn so erzeugt, dass die dabei entstehende Form des Weltkontaktes eine phänomenologische Analyse des Sinnerlebens ermöglicht, allerdings im selben Medium.
Sinn als Struktur nicht stillstellbarer Verweisung weist in jedem Moment
über die Enge des Systems hinaus. Das System betreibt Sinn, aber es ist nicht
mit der Sinninszenierung, die dabei zustande kommt, identisch.
Auf der Ebene der konditionierten Koproduktion hat das System keinen
Sinnzugriff auf sich selbst, der erst sozusagen post festum  nach dem re-entry, möglich wird – in beliebiger Ramifikation, aber zu spät, um
das Original des betriebenen Unterschieds, den wir System nennen, zu erreichen. Das System arbeitet in permanenter Selbstverfehlung. Wir haben schließlich keine oder allenfalls mystische Möglichkeit, an den reinen Zustand der Tiefe Null heranzukommen. Es verbleibt nur die Möglichkeit von Beschreibungen des Typs “improper mixture” Beschreibungen einer Nicht-Separibilität, die wir beständig oszillierend separieren müssen, von der man nicht einmal sagen könnte, dass sie ein individueller Sachverhalt ist.

Irritierend ist jedoch, dass das Problem von Sinn stark mit der Beobachtung verknüpft ist. Die Beobachtung ist nicht ohne die Paradoxie der  Selbsreferenz zu haben. Wie erkennt der Systemtheoretiker dann aber den Eigensinn eines Systems?

The art of adding features to any product or service is this:

Those who need or want the new features can find them easy.

Meanwhile those who don’t need or want the features don’t even notice them. They are invisible.

Sounds impossible to do, but I think the team at twitter are doing a pretty good job of it. The way I’d try and achieve this would be by making sure the visual structure doesn’t change, and the sequence of events to use it is not interrupted.

shhh – here comes the controversy.

Iterative enhancement is a liberating concept for software. No disc need be the canonical version of The Application, no download need be final.

But while the developers excitedly roll out version 1.2 and version 1.3 and version 1.4 and so on, there are few guarantees that users will follow the instructions telling them of the latest and greatest increment. These not unreasonable thoughts give software makers cold sweats: “It might work differently, which will confuse me” OR “it might not work on my old machine” OR “I haven’t got time to download and restart now”.

Refinements and new features represent both carrot and stick for eager users like me, but for some they’re just the carrot, and an unappetising one at that. The stick comes in two forms – persistent prompts (“there must be a limit to how many times someone can click cancel?”) and forced updates (“right, you’re not coming in until you say yes, got that?”). Actually, there is one further model – the bribe. As demonstrated by Microsoft.

This is where desktop software’s ambitious younger sibling comes in with a cheeky grin. Ever-slicker modern web apps have an edge in the iteration department. These guys make updates before breakfast, another for elevenses, two after lunch and one before home.

This is great for small tweaks, but with significant changes something funny happens. They forget to say “please”.

When large sites like Facebook and Last.fm introduce new designs, users get a shock. And then they complain. And then they complain. And they complain.

Of course, many former complainers become latter day complimenters, but it’s a rocky journey. These particularly unpopular updates were based on user research, and the findings that informed them were seemingly validated in due course. What users were not given was the chance to click cancel, as many times as they like. Forever if necessary.

Iteration and refinement are integral to modern software. A sense of control is integral to modern people.

If you’re on twitter you have probably noticed the new addition of lists to your feed. Which is the ability to create and follow lists of specific people. Cool idea, which many twitter clients like Tweetdeck had implemented a long time ago. What is not so cool, is the inference that it is purported to only be available to a limited group. If you look at the screen grab below (highlight in orange boxes) you’ll see such claims.

I understand why they’ve used such language; to make users feel exclusive, and to essentially make people tweet about it – the antithesis of what they claim to want. But I’m a bit disappointed that the crew at twitter would use such low ball, inauthentic tactics. I say this because everyone I know with 10 to 10,000 followers has been invited to lists.

Startup blog says – stay true.

Internal iterators like foreach tend to do very well in micro-benchmarks on the JVM. In fact, they often do as well as the equivalent manual while or for loop. There is a catch, however, and it’s easy to miss it in micro-benchmarks.

A few months ago, David MacIver forwarded an email from Martin Odersky to the scala-internals mailing list about this. The problem as described by Martin:

“The reason seems to be that the foreach itself is not inlined, so the call to the closure becomes megamorphic and therefore slow.”

I was curious about the benchmarks used to measure this and Tiark Rompf (who had performed the measurements) provided the source code. I said I’d try to take a look the next weekend and I did it… more than 3 months later. Well, better late than never.

There are 3 benchmarks:

• Benchmark A: traverse a collection with N elements
• Benchmark B: traverse a collection with N elements, inside the loop/closure traverse another collection with N2 elements 3 times
• Benchmark C: build a collection (front to back) of N elements

Various approaches are used for each benchmark with various collections types. One weakness of the these benchmarks is that they don’t include a verification mechanism to ensure that all benchmarks produce the same result. However, they include code that tries to prevent the JIT from performing unfair optimisations (e.g. print something if an element in the collection matches a certain condition).

The original results produced by Tiark can be found here.

I added a few benchmarks that use plain arrays (RawArrayIndexed, RawArrayForeach, RawArrayForeachMega), made minor changes to the scripts and pushed the code to a GitHub repository. I left the rest of the Scala code as it was to make it easy to compare with the original results and ran the benchmark with various JVM settings to see what effect they would have. All the tests shared the following:

• Dual quad-core Xeon E5462 2.80GHz
• 14 GB RAM
• Fedora 11
• Scala 2.8.0.r19261
• Revision 59521431f5c118b73e35b0b396e3efd6aecec3dd of project
• 64-bit JDK 6 Update 18 early access b03
• JVM base settings: -Xms1G -Xmx1G -XX:+UseParallelGC -XX:+UseParallelOldGC

JDK 6 Update 18 is scheduled to be released on Q4, 2009 and it includes HotSpot 16. Even though JDK 6 Update 14 (HotSpot 14) introduced compressed references and scalar replacement, HotSpot 16 includes improved compressed references and many crucial fixes to both features. According to my testing these features are now approaching production-level stability and the OpenJDK engineers seem to agree as they are both enabled by default in HotSpot 17 (which will eventually hit JDK6 too).

Interested in how these features would affect the performance in these benchmarks, I ran them with various combinations. I also added Scala’s compiler -optimise flag in some cases.

The original benchmark from Tiark used 3 collection types: array (java.util.ArrayList), list (scala.List, immutable single linked list) and vector (earlier version of immutable vector that has recently been added to Scala 2.8). I added JVM arrays and they are shown as “rawarray” in the charts. Finally, we get to the actual numbers.

Click on chart for expanded version

There are some interesting data points here:

1. Compressed references is a _huge_ win. RawArrayIndexed went from 500ms to 142ms and many of the vector operations were much faster.
2. Escape analysis (which enables scalar replacement) doesn’t seem to have much of an effect.
3. scalac -optimise doesn’t seem to have much of an effect.
4. foreach is misleadingly fast in micro-benchmarks, but it’s easy to bring it down to earth. RawArrayForeach performs similarly to RawArrayIndexed, but RawArrayForeachMega is 10 times slower. The latter simply calls foreach with a few different anonymous functions during the collection creation phase causing the call site to become megamorphic. Once this happens, the only hope for good performance is that the foreach method gets inlined and it doesn’t seem to happen here. With this in mind, it seems like ticket 1338 (Optimize simple for loops) is a good idea.

Click on chart for expanded version

Once again, compressed references are a large factor in some benchmarks (halving the time taken in some cases).

The new bit of information is that scalac -optimise causes a huge improvement in VectorForeachFast and VectorForeachFastProtect. This makes sense once one considers one of the findings from the previous benchmark. We said that inlining of foreach is of extreme importance once a call site is megamorphic and this is precisely what -optimise does in this case (and the JVM fails to do so at runtime otherwise). Sadly, -optimise cannot do this safely in many cases as it’s shown by the results for VectorForeach.

Click on chart for expanded version

Once again, compressed references provide a nice boost. Seems like this option is a winner in 64-bit JVMs (if you don’t need a heap larger than 32GB), it saves memory and gives better performance. The usual disclaimer applies though, you should benchmark your own application instead of relying on micro-benchmarks when deciding what JVM options to use.

The complete results are also available. Feel free to play with the source code and provide your own numbers, fixes and/or improvements.

Some time ago I posted a little program to calculate a rough approximation for the conformation of AB₅ molecules with. As I started dealing with the stuff again I improved the program somewhat. First of all I corrected part of the “violent” code from the first version.

Secondly, I’ve added the possibility to assign relative charges to the ligands. You can play around a little e.g. by giving two ligands a charge of 1.2 while the remaining three are charged with 1. You will see, that the higher charged ligands no longer occupy the energetically unfavorable axial positions. But when overdoing it, i.e. making the difference too large, the repulsion in the equatorial plain will become too high resulting in a completely different arrangement with the two higher charged ligands again choosing positions that are something like axial. It is also possible to assign the charge zero or negative values to the ligands. This doesn’t make much sense, however.

As a result of old wrong decisions in the structure of the program, it is not possible to directly enter the absolute number of ligands. But you can change the fourth line in the source code from

int numberofligands = 5;

to any number of your choice. After that, the program needs to be compiled again, of course. (This is a very ineloquent solution but currently, I didn’t want to write the whole program again.) For example, changing to values of 3 or 4 yields the familiar tetrahedral and trigonal planar structures.

However, I have brand new ideas for a completely new program that should work according to a totally different method and be much more powerful. Hence I didn’t spent too much time in updating this old version. Further news will be posted as they’ll come up…

Downloads:

• Java-Source-Code
• Compiled version (Java Runtime Environment required to execute)

If the compiled version doesn’t work, please try downloading the source code and compile yourself.

A quick and easy method to SUM/ ADD / TOTAL a range of cells in Excel is simply to select cells by using the SHIFT+ARROW KEY and the SUM will be displayed at the bottom.

You can practice minimal design to be effective with systematic reuse. The design needs to continuously look for opportunities to align iteration goals with your systematic reuse roadmap. Too many developers mistakenly think that adopting agile means abandoning design. This couldn’t be farther from the truth. You design whether you explicitly allocate time for it or not. Your code will reflect the design and you will impact the technical debt for your codebase in one way, shape, or form. Implementing user stories and paying down technical debt should be your end goal and not avoiding design altogether.

The first priority is to design for meeting your iteration goals. Avoid designing for several weeks or months and surely avoid putting technical perfection ahead of delivering real user needs. You should design minimally. Just enough to take advantage of existing reusable components, identify new ones, and plan refactoring to existing code. Specifically this means:

1. Keeping a list of short term and medium term business goals in mind when designing
2. Always looking for ways to make domain relevant software assets more reusable
3. You are aware of what distribution channels your business is looking to grow
4. Design reflects the domain as close as possible and that your reusable assets map to commonly occurring entities in your business domain
5. Value is placed on identifying the product lines that your business wants to invest in and evolving your reusable assets to mirror product line needs.
6. Design isn’t a pursuit of perfection but an iterative exercise in alignment with your domain.

What you decide to encapsulate, abstract, and scale are all natural byproducts of this design approach. Rather than spend a lot of effort with big upfront design you can do just enough design.

Like this post? Subscribe to RSS feed or get blog updates via email.

F1    Displays the Help Window

CTRL+F1 Closes and reopens Help Window.

ALT+F1 Creates a chart based on selected range of cells in the current worksheet.

ALT+SHIFT+F1 inserts a new worksheet.

 F2   This is command used by Lotus 1-2-3 users, allows you to Edit active cell.

SHIFT+F2 allows you to edit the comment in a given cell.

 F3  Pastes a defined name into a formula. SHIFT+F3 displays the Insert Function dialog box.

 F4  Repeats the last command or action, if possible. CTRL+F4 closes the selected workbook window.

 F5  Displays the Go To dialog box.CTRL+F5 restores the window size of the selected workbook window.

 F6  Switches to the next pane in a worksheet that has been split (Window menu, Split command).  SHIFT+F6 switches to the previous pane in a worksheet that has been split.  CTRL+F6 switches to the next workbook window when more than one workbook window is open.

F7  Displays the Spelling dialog box to check spelling in the active worksheet or selected range.

CTRL+F7 performs the Move command on the workbook window when it is not maximized. Use the arrow keys to move the window, and when finished press ESC.

 F8  Turns extend mode on or off. In extend mode, EXT appears in the status line, and the arrow keys extend the selection.

SHIFT+F8 enables you to add a non-adjacent cell or range to a selection of cells by using the arrow keys.

CTRL+F8 performs the Size command (on the Control menu for the workbook window) when a workbook is not maximized.

ALT+F8 displays the Macro dialog box to run, edit, or delete a macro.

 F9  Calculates all worksheets in all open workbooks. F9 followed by ENTER (or followed by CTRL+SHIFT+ENTER for array formulas) calculates the selected a portion of a formula and replaces the selected portion with the calculated value.

SHIFT+F9 calculates the active worksheet.

CTRL+ALT+F9 calculates all worksheets in all open workbooks, regardless of whether they have changed since the last calculation.

CTRL+ALT+SHIFT+F9 rechecks dependent formulas, and then calculates all cells in all open workbooks, including cells not marked as needing to be calculated.

CTRL+F9 minimizes a workbook window to an icon.

 F10  Selects the menu bar or closes an open menu and submenu at the same time.

SHIFT+F10 displays the shortcut menu for a selected item.

ALT+SHIFT+F10 displays the menu or message for a smart tag. If more than one smart tag is present, it switches to the next smart tag and displays its menu or message.

CTRL+F10 maximizes or restores the selected workbook window.

 F11  Creates a chart of the data in the current range.

SHIFT+F11 inserts a new worksheet.

ALT+F11 opens the Visual Basic Editor, in which you can create a macro by using Visual Basic for Applications (VBA).

ALT+SHIFT+F11 opens the Microsoft Script Editor, where you can add text, edit HTML tags, and modify any script code.

 F12  Displays the Save As dialog box.

 Source: Microsoft Corporation – Online Help

CTRL+A    Selects ALL
CTRL+B    Apply BOLD Formatting.
CTRL+C    COPY selected cells
CTRL+D    FILL DOWN – Copies the format of the top cell of the range to  the selected cells
CTRL+F     Displays the FIND dialog box.
CTRL+G     GO TO dialog box.
CTRL+H    FIND & REPLACE dialog box
CTRL+I    Apply or remove ITALICS formatting.
CTRL+K    Insert HYPERLINK dialog box or the Edit Hyperlink dialog box
CTRL+L    Create LIST dialog box.
CTRL+N    Open and creates a NEW workbook.
CTRL+O    Displays the OPEN dialog box to open or find a file.
CTRL+P    PRINT dialog box
CTRL+R    FILL RIGHT command to copy the contents and format of the leftmost cell of a selected range into the cells to the right.
CTRL+S    SAVE file with current file specifications
CTRL+U   Apply or remove UNDERLINING
CTRL+V   PASTE
CTRL+W   Close workbook WINDOW
CTRL+X    CUT selected cells
CTRL+Y    Repeats the last command
CTRL+Z    UNDO command

Source: Microsoft Office Online

October 22nd is the big day for the official release of the latest iteration of the Windows operating system

Source:
http://blogs.techrepublic.com.com/10things/?p=1054