S-au publicat normele de venit pe 2012. In momentul asta mai sunt cateva judete pentru care nu s-au publicat inca, dar probabil ca lista va fi completata zilele astea si cu restul.

Dupa cum probabil ati auzit pana acum, marea schimbare in ce priveste normele de venit pe anul acesta e ca s-au scos aproape toate normele pentru CAEN-urile din IT, mai putin 6202 (activitati de consultanta in tehnologia informatiei) si 6203 (activitati de gestiune si exploatare a mijloacelor de calcul). Asta inseamna ca cei care au orice alt CAEN in afara de cele doua au de acum doua optiuni:

1. Trecerea la sistemul real de impozitare. In acest caz va trebui sa mergeti sa depuneti declaratia de venituri anticipate pe anul acesta. De asemenea, inseamna tinut contabilitate in partida simpla, completat registrul jurnal de incasari si plati, etc.
2. Schimbarea CAEN-ului actual in unul din cele doua de mai sus. Aici ar fi de notat faptul ca de acum orice nou contract sa fie facut pe noua activitate, ceea ce ar putea pune probleme unora. Spre exemplu, ma gandesc ca un contract de consultanta este posibil sa nu convina oricarui client, pentru ca practic nu ar mai exista obligativitatea livrarii de cod sursa sau alte materiale.
   Schimbarea de CAEN se face la ONRC. Cel mai bine sunati la sediul ONRC din judetul vostru pentru a intreba exact ce acte va trebuie pentru schimbarea CAEN-ului, cat dureaza, etc.

PS: daca cumva stirea ca s-au scos normele de venit in IT te scandalizeaza, am scris si pentru tine ceva.

1. First, bring up the TortoiseSVN menu by right clicking on your working copy.
2. From the menu, choose “Show Log”.
3. Holding down the CTRL key, select the two revisions you want to compare (like this).
4. Right click on one of the two revisions and select the Compare revisions option.
5. In the file list that appears, select all the entries (CTRL+A), right click on them and select the Export selection to… option. The files will be exported with the right directory structure, so all you have to do is upload them to the server.

Unfortunately, this method only works for new files or files that have been changed. The files that have been removed will have to be manually deleted from the server too.

There are, of course, tons of better tools to deploy files to FTP servers that can also handle removed files (Springloops is my current favorite), but this is quick and easy way to do it when you don’t have a better solution on hand.

First, download Shadowbox. As of this version, the downloaded files are automatically minified, so in order to be able to properly add the needed code you will have to prettify the code, using a tool such as http://jsbeautifier.org/.

After you have prettified the code, scroll down right after the onWindowResize method, which should look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13

k.onWindowResize = function () {
    if (!P) {
        return
    }
    I();
    var K = g.player,
        S = R(K.height, K.width);
    t(S.width, S.left);
    E(S.innerHeight, S.top);
    if (K.onWindowResize) {
        K.onWindowResize()
    }
};

The reason I am including the onWindowResize method is because, the code being packed, the variable names might change in subsequent versions of Shadowbox, so you will have to take a look at an existing function. Now, right below the onWindowResize method, add the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

k.dynamicResize = function (w, h) {
    if (!P) {
        return
    }
    I();
    g.player.width = w;
    g.player.height = h;
    var K = g.player,
        S = R(K.height, K.width);
    t(S.width, S.left);
    E(S.innerHeight, S.top);
    if (K.onWindowResize) {
        K.onWindowResize()
    }
};

Notice that there are only three lines that differ between the two methods. After adding this method (and perhaps minifying the code again), you can easily resize the modal like this:

1

Shadowbox.skin.dynamicResize(600, 400);

Or, if you want to do it from inside the iframe loaded within the modal:

1

window.parent.Shadowbox.skin.dynamicResize(600, 400);

Note that this method does not resize the window beyond the viewport dimensions. It will still be scaled down if it exceeds the viewport’s width or height.

6 months ago I decided to try out the Pomodoro Technique, so it’s about time to document my findings. First of all, I cannot image going back to the way I used to work before. It seems too chaotic and disorganized now that I got used to the mechanical precision of the technique.

Some things I learned:

• As I first suspected, the technique helped me accomplish a larger and more efficient quantity of work than before, with a lot less interruption, and a lot less room for procrastination. Not that you cannot procrastinate, it’s just that it’s more obvious to yourself when you do so. If you try reaching for 12-13 pomodoros on an average day, the days when you only manage to churn out 6 or 8 will stand out like a sore thumb.
• I now think of tasks in terms of the number of pomodoros it takes to complete them, so it gave me an excellent unit of measurement for use in estimating.
• Most of us don’t work in an isolated environment, and it’s sometimes hard not to be interrupted, and I think this problem only grows as the size of your organization increases.

Some tricks I used to adapt the technique to my own needs:

• Starting a new pomodoro is sometimes hard. I now have the habit of leaving a small amount of work not done at the end of a pomodoro, and when the break is over this forces me to jump right in and finish what I started. It’s a lot easier to procrastinate when the code is stable and everything works.
• I try and time my pomodoros with my lunch break. Therefore, I don’t take a larger break until after the 5th or 6th pomodoro, which usually ends just as we are all about to go out for lunch. Otherwise I would take my lunch break after just 2 pomodoros.
• I started using the technique by scribbling the number of pomodoros that passed on a little piece of paper. I have, since then, advanced to using a daily to-do list, and marking each pomodoro on the row of it’s corresponding task. This serves a double purpose as, besides tracking the daily pomodoro count, it helps with the future estimation of similar tasks.

Some of the adjustments I made (particularly the first one) directly contradict the book. I don’t think that’s too bad, because the entire technique’s role is to help me become more productive, and if I found a way to improve on this (for my particular case, of course), I think it’s OK. So go ahead and roll your own, as long as the changes you make boost your productivity. However, I strongly recommend sticking to the instructions in the book for the first few months, and then decide if it works for you out of the box or if it needs tweaks.

I was meaning to start writing about books for some time now, but I also didn’t want to pollute this website with non-technical information so, for those of you that are interested, I will be massacring the English language on my other blog too, Walk Into Mordor.

Happy reading!

De acum incolo titlul meu (pe langa “Comandant Suprem al Fortelor Imperiale“) este “Programator la Data Solutions“.

De ce?

Pe scurt: pentru a programa.

Pe lung: am inceput treaba la HyperActive ca web developer, si in aceasta perioada am invatat mult, am crescut mult, pana am ajuns in punctul in care ma simt gata sa urc inca o treapta, iar acea treapta o reprezinta lucrul pe software web si aplicatii intranet. Programare.

HyperActive are si va avea in continuare succes ca agentie interactiva, cu clienti si proiecte importante in domeniul advertising-ului si marketing-ului digital, iar eu personal le doresc tot binele din lume. Din pacate satisfactia mea interioara vine din alt tip de proiecte.

Ce am realizat?

Nici nu stiu de unde sa incep.

• Am dobandit foarte multe cunostinte tehnice, atat de programare cat si de administrare a unui server.
• Am optimizat modul de organizare si deployment a proiectelor, pana in punctul in care orice membru al echipei poate face deploy cu incredere la ultima versiune a unui proiect din cateva click-uri.
• Am fost avocatul descentralizarii si organizarii pe echipe de proiect self-managed.
• Am cautat in permanenta cai de imbunatare, atat a codebase-ului cat si a metodelor si proceselor de lucru. Am si reusit de multe ori.
• M-am dat pe reddit.com. Mult :D

Toate astea datorita si impreuna cu partenerul meu de batut cap in cap in gasirea solutiilor, Gabriel Solomon.

Regrete?

Echipa. Fara discutii.

Poate mai important decat realizarile de mai sus, HyperActive mi-a dat ocazia sa beneficiez de sentimentul inaltator de a fi persoana la care colegii tai apeleaza cand au nevoie de ajutor sau cand sunt blocati.

Ovidiu Boc imi spunea mai demult ca satisfactia succesului colegilor tai, succes la care ai pus si tu umarul, o depaseste uneori pe cea a succesului personal. Avea dreptate.

Ce urmeaza?

In primul rand urmeaza acomodarea si stabilirea la noul birou. Apoi un proiect in privinta caruia sunt foarte entuziasmat. Apoi … multa munca, multa joaca, invatam si ne dezvoltam in permanenta, altfel nu merita.

In the raging, aeon-spanning battle against procrastination, I am constantly on the lookout (while procrastinating, of course) for ways to improve my productivity and help me work more efficiently. This is how I stumbled on The Pomodoro Technique, and gave it a try.

The rundown

At it’s core, the technique consists of splitting your work in 25 minute intervals, with a 5 minute break between each interval, and a longer break (15-30 minutes) after 3-4 such intervals (pomodoros).

In theory, it should help you stay focused and productive, by timeboxing your tasks into undividable chunks and then help you analyze and measure your productivity in uninterrupted pomodoros.

The trick is, if you somehow get distracted during a pomodoro (either by other people or by yourself), that pomodoro no longer counts. Even if you happen to take “just a peek” at reddit’s homepage in the 23rd minute (although you and me both know there is no such thing as “just a peek” when it comes to reddit.com).

After the first few days with just a few finished pomodoros per day, you will do your best to avoid interruptions.

Will it help me avoid said interruptions?

No, it will not. It will only make the measure in which these interruptions affect you crystal clear, by showing you just how little actual uninterrupted work you do each day. The book does have an entire chapter dedicated to interruptions and how to handle them, and it’s a short read.

Is it worth it?

First of all, it’s not a silver bullet. There are no silver bullets. It all boils down to your own resolve in sticking to a pattern and work in a less chaotic manner. I find it worthwhile and plan to keep using it for now, for the following reasons:

• Two pomodoros make an ideal work hour (hour of actual continuous work), which is just the right unit to use as a Story Point to measure User Stories in.
• It helps with estimating and breaking down tasks, because it makes you split longer tasks into smaller, more specific and manageable units (more about this in the book).
• It delivers what it promises: a mechanism to keep you focused and avoid … temptations.

So go ahead, give it a try, but keep in mind, it will be hard at first; it will hurt your feelings, and like with all things that shine a light on existing problems, you will be tempted to give it up pretty soon.

The release date is closing in, you manage to wrap everything up, and launch. You lean back in your chair and think to yourself “ahh, another job well done”.

Then, out of nowhere, after just a few hours in, your task list / inbox gets filled with things like “How can I do X?”, “We have an issue with Y” and the dreaded “Z isn’t working”. You open the list, scan the first few items, and it hits you:

“Wait a minute, we’ve been over these, this is the way this feature was supposed to work, it’s been tested.”.

Ahh, but you see, it wasn’t.

But how could this happen?

Here’s the thing: your customers don’t really test. Your project managers don’t really test. You don’t really test. Not until the lauch date that is. That’s when everyone really starts testing.

“But, we had at least 6 people involved in this project at all times. Surely between them they tested everything”.

Well, not really, no. You see, every person involved in your project has a certain way of  looking at it.

You have a list of features that needs implemented. While you churn out feature after feature, you only tend to test the specific behavior you built into each one. “Right, so the user clicks this, fills out this form, and ends up here.”.

You don’t really try to break your own application, so you only interact with it in the way it’s meant to work. And of course, it works … “on your machine”.

Your project managers don’t test because they don’t have the time for it, because they have that meeting about that other project with that other client in 10 minutes, just pop them an email and they’ll look it up later … They won’t. They’ll be too busy.
They’ll rephrase parts of your email (because really, you suck at writing to corporate clients), and forward it to the customer. And they will not get a chance to test it again … until after the lauch date, when …

… the customer will start testing. The customer, the person you build the entire project for, doesn’t even remotely start testing until after the project has set sail. Why? Because until then, to them, the project is not real yet. It’s “under construction”.

They will open it up, have a peek, and unless something is downright wrong, they will not notice it. They will not follow the individual interaction flows, they will not start using the project like they will use it for real. “Oh, I can see some products, that probably means the entire administering, checkout and billing processes must be working.”.

Most of the problems that will rise from the customer’s lack of testing are those when he expects a feature to work a certain way, but he described it to your project manager at first in a totally different way. And she described it to you in yet another way. And you developed it “your way”.

Who’s fault is it?

No one’s really. All of yours.

• The client is thinking “I pay these people a lot of money, and the product is full of problems, I wanted something else.”.
• The project manager is thinking “It’s that arrogant developer’s fault, I distinctly remember giving him precise instructions on how this should work”.
• We all know what you’re thinking … “These damn mortals better let me get back to reddit.com”.

Who should test?

First of all, nothing beats professional testing. Ideally, you should have dedicated testers, but odds are you will have to make do with what you have available.

So there is good news, and bad news:

The good news is that, when searching for bugs, it’s easy! Grab a few members of your team that don’t work on this particular project. Best to do this with all types of colleagues: other developers, account managers, even the office secretary.

Sit down with them, and politely ask them if they can spare any amount of time to test your product. Then assign them some user roles, and let them loose.

The bad news is that application bugs are the easiest to find and fix. The biggest issues come from what I said earlier: miscommunication.

• The customer is not skilled in describing his needs. Most of the time he doesn’t even know his needs, and this is absolutely normal.
• Your project managers don’t have enough experience in the customer’s business field, or not enough technical skills. So they interpret the customer’s requests, and relay them to you wrongly.
• In-house problems. Trust issues and other problems can seriously affect the way people work together and communicate (more on this soon).

My bet is that shorter release cycles, more customer involvement (the project managers really have to step up here), and enhanced communication can at least lessen the impact of these problems on the typical project. Also, the User Stories and Acceptance Tests agile development concepts fit perfectly.

The easiest thing to do was to use the mod_rewrite, mod_proxy and mod_proxy_http Apache modules. You can easily activate all of them in Ubuntu with:

1

sudo a2enmod rewrite proxy proxy_http

I created an empty folder on the server and placed a .htaccess file with the following lines in it:

1
2

RewriteEngine On
RewriteRule ^(.*)$ http://10.4.2.155/$1 [NC,P]

The [P] at the end of the RewriteRule specifies that the request should be handled by the proxy module so all GET and POST data are preserved. Therefore, all requests made in that directory will be automatically forwarded to my machine.

So if the WSDL location is:

http://example.com:33080/soap/server/path?WSDL

All requests after fetching the WSDL file will be made to:

http://example.com/soap/server/path

The simplest way i could work around this was to extend SoapClient and intercept the constructor and the __doRequest method to inject the port in the location on each request:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

<?php
class My_SoapClient extends SoapClient {
 
    public function __construct($wsdl, $options) {
        $url = parse_url($wsdl);
        if ($url['port']) {
            $this->_port = $url['port'];
        }
        return parent::__construct($wsdl, $options);
    }
 
    public function __doRequest($request, $location, $action, $version) {
        $parts = parse_url($location);
        if ($this->_port) {
            $parts['port'] = $this->_port;
        }
        $location = $this->buildLocation($parts);
 
        $return = parent::__doRequest($request, $location, $action, $version);
        return $return;
    }
 
    public function buildLocation($parts = array()) {
        $location = '';
 
        if (isset($parts['scheme'])) {
            $location .= $parts['scheme'].'://';
        }
        if (isset($parts['user']) || isset($parts['pass'])) {
            $location .= $parts['user'].':'.$parts['pass'].'@';
        }
        $location .= $parts['host'];
        if (isset($parts['port'])) {
            $location .= ':'.$parts['port'];
        }
        $location .= $parts['path'];
        if (isset($parts['query'])) {
            $location .= '?'.$parts['query'];
        }
 
        return $location;
    }
}

It works for me, and I would like to know if it doesn’t cover your particular case :)