Week ceil(pi)Created on 20131024
Requirements are better than planning. I know that probably I should embrace both as good strategy for work, but I just can't. I am more the strategy guy than tactics guy. I like to know that in chess the goal is to checkmate the opposite king. This is the requirement. Now how I'm going to do that - using pawns, bishops and knights - I want to have the flexibility to do that. I don't want to make my first move and define my whole game. I like the dynamics, dealing with unforeseen positions.
There is this big difference I see which makes me want to have good requirements but not necessary a strict plan to execute them (see rant about planning, pre-previous blog post). But the specifications are whole different world - I would like to know what is the final deliverable, what needs to be done.
Describing this with the help of the UML is best. One language to rule them all - standartization is good practice and it's of the rare case that UML was created. Drawing the diagrams, writing the use cases shows you a good picture of what the final thing will look like. It's so good that you can draw java class hierarchies and tiny actors and use the same universal approach. Good things.
To keep it rolling from the last week, I rewrote a famous song about the requirements.
We Will Require
At first, we were afraid, this was not defined.
Kept thinking, we could never write the specs we were assigned.
But then we read so many slides thinking how we did it wrong.
And we did what we shouldn't have prolonged.
And now we write, and ask and chase
proffessor Singer down the corridor, refining our case.
We should writte that good old doc.
We should made a guarantee.
that this will not impact, oh no, the mark on our degree!
Could, would, should, won't - the keywords are.
What do we need - we won't ponder anymore.
Who though of that? It just didn't ring a bell.
Who could know? ... We had to use the UML!
Oh, no, not we, we will require!
Oh, as long as we know how to trac, we'll keep a good attire.
We've got all specs to give, we've all got to get relief
And we'll require! We will require, hey, hey!
Week floor(pi)Created on 20131019
I can't be more confused about git. I'm using it for about two years, pretty regularly, I get the point, I know it's good. But somehow I always manage to screw things up.
Every time I discover something new about git, I love it and I think "NOW I got it!". And after few minutes, git slaps me like a lemon tied on a brick (H2G2 ref). I wish I could work better with it. I went through so many tutorials, I worked with it, I asked for help from more proffesional users. And I still manually copy the directory just in case. Version control is good, the idea is great, I love it to be able to undo things, to see how a project evolved with history, to branch and play on a new feature. But does it have to be so complicated? Can't it be ala Google Docs solution? Future will show.
In the meantime - I decided to write a poem about git. It's rephrased very epic poem we have in Bulgaria called "The Rebels on Shipka" and it describes one of the last battles we had with the Ottoman empire back in the end of XIX century. I love it so much, I decided to take a spinoff of it. There it is:
Ode to Version Control
Oh, Version control!
Three weeks already the young and the brave
the code they manage - and not misbehave!
Github valleys eagerly repeat the roar of the battle.
Horrible pushes! For the dozen time the old merges rattle,
and fastforwards automatic clear some mess.
Commits after commits! Pushes after pulls!
The scrum master is pointing to the specs
and shouts "Branch it first! Perform all checks!"
And developers rebase, they talk and then agree.
But github answers with another shout: Permission denied (publickey)!
And with new rain of checkouts, statuses and logs,
everyone blames, and clones, and forks.
They code like lions, they compile like sheeps.
The last commit had broken the release.
And again git wins. The geeks disapointed, frustrated
just do in the bash:
rm -rf /
But the day will come,
trust me, I know,
where we will understand
how to use version control.
Week 10Created on 20131011
This week - charts.
Almost. But not quite. We were talking about Gantt and PERT charts. Cool stuff that bussiness people talk all the time. They just love it - give them meetings, status reports, where is it going, how much is it gonna cost, who is working on what, what needs to be done in order to AAA! Just do IT!
To be honest - I hate planning (no way, you couldn't have guessed from the rant above). Not just the process of planing, the execution of it. I just can't work with a plan - it limits me or it pushes me - never with the right speed. The right speed depends on many factors including distance and time but in this context - my current mood, level of entropy in the Universe and amount of food around me. The bad thing is that it's a must do and not want to do - and that's all the difference for me. I'm the kind of person that just wants to do the work, not plan it.
But... some people need it. Some people need to know what is going on when and how. And because I must to work with other people, I will do my best to draw charts.
First week of lecturesCreated on 20131003
My impressions of the first week of 3rd year at University is that this year it will be really busy. We already have assigment sheets and we are jumping straight into the difficult work - no more lazy introductions. Which is good.
Our team project was announced - TweetDesk. It's gonna help journalists mainly to find emerging topics in twitter. Twitter is great, but I also noticed from my ussage that it's not too good to follow too many entitites, since the noise overwhelms the useful information. With our project, we are going to try to fix that.
We also met our project supervisor and the 2 PhD guys who will be helping us. As far as we understood in this early stages, we will be mainly working on the front end. This is great news for me since I am already interested in beautiful and simple design and visualisations. Moreover, I worked on similiar tasks during my summer internship and I have some experience.
As far as the codebase goes, as far as I am concerned, we should have some backend algorithms for data scraping and event allocation and lots of testing data from historical twitter posts. It is mainly written in Java, but there will also be code from Go, Python and others.
On the PSD lecture, we learned about different design models, some historical like the waterfall, V and spiral and the more recent ones like agile development. I particularly like the agile techniques since it gives you what matters for the whole project and end product and not what matters for some manager who is not involved at all in the project. This makes more sence for me. The team's feelings are also similiar, so we chose to go with this approach for other projects and specifically chose the scrum method. We will try dynamic allocation - i.e. no single individual will be scrum master for the whole process, but rather the scrum master "hat" will change in individual sprints.
So far, so good, let's see how next week will be.