Tuesday, October 19, 2010
The best summary of visualisations techniques ever
Thanks to Sorin Mocanu, I saw this comprehensive overview about interesting visualisation techniques.
Monday, September 6, 2010
Design with Intent
Wow! This is sooo interesting! Have you ever wondered how to influence someone with small things?
Design with Intent wiki page - this may give you a hint on what is small around you and matters.
By the way, maybe that will change the way you think about things.
Saturday, September 4, 2010
Placek jabłkowy (polish)
[I think I should find a different place for posts like that.]
Z okazji przyjazdu mego dziewczęcia postanowiłem przygotować słodką niespodziankę. Przy podanej tutaj ilości składników można wykarmić cały batalion, więc proponuję następujące poprawki:
- ilość wszystkich składników podzielić przez 2;
- zrobić więcej ciasta (około połowy więcej).
Wychodzi więc na to, że trzeba użyć składników w następującej ilości:
Z okazji przyjazdu mego dziewczęcia postanowiłem przygotować słodką niespodziankę. Przy podanej tutaj ilości składników można wykarmić cały batalion, więc proponuję następujące poprawki:
- ilość wszystkich składników podzielić przez 2;
- zrobić więcej ciasta (około połowy więcej).
Wychodzi więc na to, że trzeba użyć składników w następującej ilości:
 | |
- 2 i ćwierć szklanki mąki
- 5 łyżek cukru
- 1 kg jabłek
- 15 dag orzechów
- 10 dag rodzynek
- 3 jajka
- 3/8 szklanki oleju, a więc nieco mniej niż pół
- 3/4 cukru waniliowego (cały też może być ;-))
- 3/8 startej cytryny, a więc nieco mniej niż pół
- 3/4 łyżeczki proszku do pieczenia z czubkiem
- 3/4 łyżeczki sody
 |
| Po upieczeniu wygląda znacznie lepiej. |
Why PHP sux (polish)
If you we're thinking of a couple of good reasons why PHP sucks, here's a handy summary (in polish, brought to you by yanoo).
Why I don't like Java's finals
Although I favor immutability over mutability, I must say that I don't like Java's finals. The intention when introducing it was definitely great and good, but I think it does more harm than provides benefits.
Consider the following.
Finals prevent you from mocking classes.
Yes, they do. I hardly know any framework that is capable of mocking class that is final; you can play with some workarounds like unfinalizers or framework extensions to do the trick, but it comes for the price of a test / test set-up complication (at least) and an additional cost (running time, introduction time).
There are people who suggest that you don't need to mock classes for your tests, but I hardly find it acceptable: imagine yourself writing unit tests for class that uses a "final" server as a parameter:
class LogCollector {
public LogCollector(LogServer server) {
// whatever
}
}
I personally prefer to use fine-grained tests before running large test routines (requiring real server instance set up, for example), but given the server is final, I have no choice - I am left with large tests, with all their costs.
Finals lie to you.
Consider the following code:
final Set customers;
It's true, that once assigned, the customers set cannot be assigned once again, but you can still modify the set anyway - it's a matter of calling customers.add(Customer). Unless you're using an UnmodifiableSet, nothing prevents you from changing it's contents.
Finals force you to predict future.
I'm not much of a subclassing fan, but it is understandable to subclass something from time to time to enhance a bit the functionality already given. With finals, you can't do that by design. Thus, you have to predict the possible future use of your objects - and I feel no one was able to do that for something more complicated than a primitive type.
Disabling subclassing may also be a pain in an inflexible type system like Java's:
class NoisyCar {
void run() {
System.out.printl("BRRRRRRUUUUUUM");
}
// other methods
}
class QuietCar {
void run() {
System.out.printl("brrrrrruuuuuuum");
}
// other methods, same as in Car
}
X rentedCar = carRentan.getAvailableCar(); // We don't know what do they have available, but we need a car immediately
What's the type X?
Possible solution 0: Ducktyping. Not in Java.
Possible solution 1: We could use an interface Car, but then we get some serious code duplication (we would have to either copy-paste other methods or refactor out common code to a separate class, which may - in this case - seriously complicate your life).
Workaround: If we had functions as first-class values, we could probably come up with not a bad workaround and carry on with finals, but... well, we don't have them in Java.
Possible solution 2: Allow removing final, introduce a superclass and let NoisyCar and QuietCar subclass it.
Any other ideas?
Finals prevent you from flexible debugging.
I've found out that recently: while debugging, you cannot change the value of the final variable (it's not a surprise, though). What's the problem? You cannot experiment - while debugging, you cannot change the value of an interesting variable and thus you're sticked to a certain path of execution. Bad, if you encounter it in real life.
Finals encourage bad practices.
Namely, they encourage you to expose fields of a class. Since no one can change them, what's the big deal? Well, there is. You're explicitly saying the class users: this field is publicly available. You can use it. Once you change your mind and, for example, decide to provide an active getter (fetching missing data, for example) with some decoration around it (like sanity checks) you can't - someone uses the field already. And you cannot deprecate a field to let users know it's going to be gone, can you?
On one hand, it's bad to create not-fully-initialized objects. On the other, lazy evaluation may be a great optimization. It's all up to the case you're dealing with. Will finals help you? Well, they limit your flexibility and let the implementation leak, so you may have trouble.
That's my 2 cents. Please read both why finals should be deprecated and why they shouldn't and make up your mind. In my personal opinion, they rarely are worth using.
Edit: there is some follow up on this post here.
Consider the following.
Finals prevent you from mocking classes.
Yes, they do. I hardly know any framework that is capable of mocking class that is final; you can play with some workarounds like unfinalizers or framework extensions to do the trick, but it comes for the price of a test / test set-up complication (at least) and an additional cost (running time, introduction time).
There are people who suggest that you don't need to mock classes for your tests, but I hardly find it acceptable: imagine yourself writing unit tests for class that uses a "final" server as a parameter:
class LogCollector {
public LogCollector(LogServer server) {
// whatever
}
}
I personally prefer to use fine-grained tests before running large test routines (requiring real server instance set up, for example), but given the server is final, I have no choice - I am left with large tests, with all their costs.
Finals lie to you.
Consider the following code:
final Set
It's true, that once assigned, the customers set cannot be assigned once again, but you can still modify the set anyway - it's a matter of calling customers.add(Customer). Unless you're using an UnmodifiableSet, nothing prevents you from changing it's contents.
Finals force you to predict future.
I'm not much of a subclassing fan, but it is understandable to subclass something from time to time to enhance a bit the functionality already given. With finals, you can't do that by design. Thus, you have to predict the possible future use of your objects - and I feel no one was able to do that for something more complicated than a primitive type.
Disabling subclassing may also be a pain in an inflexible type system like Java's:
class NoisyCar {
void run() {
System.out.printl("BRRRRRRUUUUUUM");
}
// other methods
}
class QuietCar {
void run() {
System.out.printl("brrrrrruuuuuuum");
}
// other methods, same as in Car
}
X rentedCar = carRentan.getAvailableCar(); // We don't know what do they have available, but we need a car immediately
What's the type X?
Possible solution 0: Ducktyping. Not in Java.
Possible solution 1: We could use an interface Car, but then we get some serious code duplication (we would have to either copy-paste other methods or refactor out common code to a separate class, which may - in this case - seriously complicate your life).
Workaround: If we had functions as first-class values, we could probably come up with not a bad workaround and carry on with finals, but... well, we don't have them in Java.
Possible solution 2: Allow removing final, introduce a superclass and let NoisyCar and QuietCar subclass it.
Any other ideas?
Finals prevent you from flexible debugging.
I've found out that recently: while debugging, you cannot change the value of the final variable (it's not a surprise, though). What's the problem? You cannot experiment - while debugging, you cannot change the value of an interesting variable and thus you're sticked to a certain path of execution. Bad, if you encounter it in real life.
Finals encourage bad practices.
Namely, they encourage you to expose fields of a class. Since no one can change them, what's the big deal? Well, there is. You're explicitly saying the class users: this field is publicly available. You can use it. Once you change your mind and, for example, decide to provide an active getter (fetching missing data, for example) with some decoration around it (like sanity checks) you can't - someone uses the field already. And you cannot deprecate a field to let users know it's going to be gone, can you?
On one hand, it's bad to create not-fully-initialized objects. On the other, lazy evaluation may be a great optimization. It's all up to the case you're dealing with. Will finals help you? Well, they limit your flexibility and let the implementation leak, so you may have trouble.
That's my 2 cents. Please read both why finals should be deprecated and why they shouldn't and make up your mind. In my personal opinion, they rarely are worth using.
Edit: there is some follow up on this post here.
JavaScript quirks explained
Ha! It's good to see that blog to help you in understanding what are you playing with when hacking JavaScript. Check out the references (1, 2), too!
Friday, August 13, 2010
Wednesday, July 28, 2010
Tuesday, July 27, 2010
How leaders inspire action
This is great (and complementary to Tribes book by Seth Godin) video on how leaders inspire action, what is necessary to make success, and the Diffusion of Innovation Law:
Simon Sinek: how great leaders inspire action
By the way, if you haven't tried TED, make sure you do so.
Simon Sinek: how great leaders inspire action
By the way, if you haven't tried TED, make sure you do so.
What motivates us
Given my experience as a President of Computer Science Students' Association at my university and my recent readings (be careful! Hardcore evangelism!), I started to investigate a bit about successful, modern leadership. If you're interested, have a look at this video:
The surprising truth about what motivates us
The surprising truth about what motivates us
Wednesday, July 21, 2010
Installing Skype for Fedora 13
Installing Skype on Linux is always a pain. After installing Fedora 13 x86_64, the following solution worked:
And, the good thing is, my mic and camera worked out of the box with it!
And, the good thing is, my mic and camera worked out of the box with it!
I hope it will work for you too.
Saturday, July 17, 2010
Why you should speak perfect English in IT
I bet you've heard that at least a couple of times: "Learn English, man, it's crucial in industry". Indeed, it is. No doubt about that. But how far should we go? We're never going to be able to challenge native speakers anyway, right?
You're not going to like the answer.
Level 1 - local backyard
English is crucial for a couple of reasons. First of all, it's a lingua franca of computer science and software engineering (actually, not only there, as you may have noticed). You talk English with team mates, you read reports written in English, you read blogs (guess the language!), you write code in English (don't dare to tell me you don't!)... English, English, English.
Secondly, almost all knowledge in this industry is presented in English, and the only reasonable way to take advantage of it is to learn the language (don't bother yourself with waiting for everything to be translated - that is simply impossible). If you want to be a better engineer, you have to read in English.
Thirdly, you'll have to speak from time to time with foreign employees, and the easiest way would be to use English, since everybody speaks it.
The basics of English should suffice, right? You can read, you can write, you can talk with other people. You'll survive.
Unfortunately that's true for a company far less international that you would expect.
Level 2 - facing the real world
When you get to a real international company, basic English is not enough. After joining a company that hires lots of people of different nationalites, you get exposed to real English. English spoken every day, every minute. You just have to be fluent - otherwise, you'll be totally worn out by the end of the day, being tired of translating everything both ways. You may get exhausted even sooner, if you're not lucky or qualified enough. That hinders you from expressing properly your thoughts and ideas, you loose your self-confidence, you make mistakes - both while talking to other people and coding. That boils down into one serious problem: you seem to be underqualified for other people. They get a bad impression about you. You loose points.
If your English is not good enough, you may run into problems with dealing with other people. You will simply be unable to communicate with them, solve problems or simply conduct design discussions. You won't be able to defend your ideas. You won't be able to even present and - worse - sell them.
And, most of all, you'll find it hard to become mates, and that may result in isolation and/or slower progress at work.
Fluency in English is also crucial for sucessful leadership. It's not an advice useful for PMs only. Without being able to communicate fluently, you won't be able to lead your co-workers. You may be pushed aside a bit. You won't have influence. Having no influence will be frustrating and you'll get the bonuses related to frustration, like getting bald soon.
Someone experienced, during one of his talks to students at my university, gave a hint how good your English should be:
You should be able to give this presentation in English as fluently, as you would do in Polish.
That's a good hint, but I believe this is the lower bound. Personally, I think you should not only be able to give a presentation in English as fluently as in Polish, but also be able to make it as enjoyable as you would do if you present something that you're really into.
That's all about selling.
Imagine you are speaking English with all of your co-workers (native speakers and people who actually do that: you can skip the excercise, and the whole rant as well). Imagine yourself not being able to get the jokes, come up with a funny reply, defend your position in the tribe. Will you achieve the same thing - position, status, respect? I seriously doubt. And what happened to the people that did not get the jokes?
Level 2.5 - emmigration
If it happened to you that you had to emigrate, you may have found that speaking fluently with people living at the place you just moved in (I assume that's a place where local yokels speak different language than you do) is somehow crucial to make them become your new friends. And making new friends outside of your home country is hard. It's all a matter of psychology - in the long run, you'll need these people so that you have someone to chat with or enjoy local events. It's not a problem of having a wife or not - people are social and enjoy packs, usually of size bigger than 2. It's also a bit different thing than at work, where it is a matter of being succesful. Here it is a matter of (enjoying) your life.
Conclusion
Speak English and never stop improving - that would be the general thought. We may not be able to challenge native English speakers in literacy or poems - but we may be able to joke with them, sell our ideas and buy theirs. We may be able to hold a position in the crowd - and not fade out in the both work.
You're not going to like the answer.
Level 1 - local backyard
English is crucial for a couple of reasons. First of all, it's a lingua franca of computer science and software engineering (actually, not only there, as you may have noticed). You talk English with team mates, you read reports written in English, you read blogs (guess the language!), you write code in English (don't dare to tell me you don't!)... English, English, English.
Secondly, almost all knowledge in this industry is presented in English, and the only reasonable way to take advantage of it is to learn the language (don't bother yourself with waiting for everything to be translated - that is simply impossible). If you want to be a better engineer, you have to read in English.
Thirdly, you'll have to speak from time to time with foreign employees, and the easiest way would be to use English, since everybody speaks it.
The basics of English should suffice, right? You can read, you can write, you can talk with other people. You'll survive.
Unfortunately that's true for a company far less international that you would expect.
Level 2 - facing the real world
When you get to a real international company, basic English is not enough. After joining a company that hires lots of people of different nationalites, you get exposed to real English. English spoken every day, every minute. You just have to be fluent - otherwise, you'll be totally worn out by the end of the day, being tired of translating everything both ways. You may get exhausted even sooner, if you're not lucky or qualified enough. That hinders you from expressing properly your thoughts and ideas, you loose your self-confidence, you make mistakes - both while talking to other people and coding. That boils down into one serious problem: you seem to be underqualified for other people. They get a bad impression about you. You loose points.
If your English is not good enough, you may run into problems with dealing with other people. You will simply be unable to communicate with them, solve problems or simply conduct design discussions. You won't be able to defend your ideas. You won't be able to even present and - worse - sell them.
And, most of all, you'll find it hard to become mates, and that may result in isolation and/or slower progress at work.
Fluency in English is also crucial for sucessful leadership. It's not an advice useful for PMs only. Without being able to communicate fluently, you won't be able to lead your co-workers. You may be pushed aside a bit. You won't have influence. Having no influence will be frustrating and you'll get the bonuses related to frustration, like getting bald soon.
Someone experienced, during one of his talks to students at my university, gave a hint how good your English should be:
You should be able to give this presentation in English as fluently, as you would do in Polish.
That's a good hint, but I believe this is the lower bound. Personally, I think you should not only be able to give a presentation in English as fluently as in Polish, but also be able to make it as enjoyable as you would do if you present something that you're really into.
That's all about selling.
Imagine you are speaking English with all of your co-workers (native speakers and people who actually do that: you can skip the excercise, and the whole rant as well). Imagine yourself not being able to get the jokes, come up with a funny reply, defend your position in the tribe. Will you achieve the same thing - position, status, respect? I seriously doubt. And what happened to the people that did not get the jokes?
Level 2.5 - emmigration
If it happened to you that you had to emigrate, you may have found that speaking fluently with people living at the place you just moved in (I assume that's a place where local yokels speak different language than you do) is somehow crucial to make them become your new friends. And making new friends outside of your home country is hard. It's all a matter of psychology - in the long run, you'll need these people so that you have someone to chat with or enjoy local events. It's not a problem of having a wife or not - people are social and enjoy packs, usually of size bigger than 2. It's also a bit different thing than at work, where it is a matter of being succesful. Here it is a matter of (enjoying) your life.
Conclusion
Speak English and never stop improving - that would be the general thought. We may not be able to challenge native English speakers in literacy or poems - but we may be able to joke with them, sell our ideas and buy theirs. We may be able to hold a position in the crowd - and not fade out in the both work.
Sunday, July 4, 2010
Thursday, June 17, 2010
Thursday, May 27, 2010
Weird TextBox.AutoCompleteCustomSource problem
It's been a while since I posted anything here, but please forgive me - I'm in the middle of finishing every project I'm currently working on before I'm gone for my internship (hooray!). Since there's a lot to be done, this time I'll leave just a short note on some weird problem I've just encountered.
So, not to prolong too much, here's the thing:
If you have encountered a "The specified cast is not valid" when running tests (I'm using NUnit) that have anything to do with TextBox AutoCompleteCustomSource (namely, when you add something to the autocomplete source via .Add(string) method), mark your test with annotation RequiresSTAAttribute. No one explained what is wrong, but the solution works. Maybe I'll investigate what's going on when I'm over and done with all of my current engagements (read it as: never ;-)).
By the way, I'm using .NET 2.0, but it may still be a problem in higher versions.
So, not to prolong too much, here's the thing:
If you have encountered a "The specified cast is not valid" when running tests (I'm using NUnit) that have anything to do with TextBox AutoCompleteCustomSource (namely, when you add something to the autocomplete source via .Add(string) method), mark your test with annotation RequiresSTAAttribute. No one explained what is wrong, but the solution works. Maybe I'll investigate what's going on when I'm over and done with all of my current engagements (read it as: never ;-)).
By the way, I'm using .NET 2.0, but it may still be a problem in higher versions.
Thursday, May 6, 2010
Possible refactorings reference list
I've recently encountered a catalog of possible refactorings created (mostly) by Martin Fowler. Although the author is a great authority known for some complex (yet brilliant!) solutions, this list is mostly consisting of the obvious refactorings you do (or even unconsciously implement along the way) on a daily basis. Although mostly simple, I encourage to get familiar with them in your spare time as there may be some things you may have missed in your (self-)development.
I would consider this catalogue a checklist of "things one should know about refactoring".
By the way, I encourage you not to follow these suggestions blindly, as there are situations in which the result of refactoring is not the desired situation (note the dual refactorings!).
Enjoy.
I would consider this catalogue a checklist of "things one should know about refactoring".
By the way, I encourage you not to follow these suggestions blindly, as there are situations in which the result of refactoring is not the desired situation (note the dual refactorings!).
Enjoy.
Innowacyjny produkt nie musi kosztować milionów
Moja ostatnia delegacja zaowocowała publikacją na nierobcietegosami.pl. Zapraszam!
Tuesday, May 4, 2010
Template metaprogramming being useful part I - Self-inlining anonymous functions in C++.
Recently - thanks to the course conducted on my University - I've become interested in template metaprogramming. During some of the discussions on that topic, I've been told that metaprogramming (and even templates!) are too complex for business use. With my previous proffesional experience in C++ (which is currently none) I couldn't obviously argue with that statement; nevertheless, I've found an interesting article accounting for usefulness of template metaprogramming - Self-inlining anonymous functions in C++, which I believe makes it worthwile to learn how to use this functional language hidden in C++ templates.
edit: thanks to Rafał, another interesting source can be found here.
edit: thanks to Rafał, another interesting source can be found here.
Monday, May 3, 2010
lifedev.net - o kreatywności, innowacji i programowaniu
Świetny blog z przemyśleniami o tym, jak tworzyć, jak nie stracić zapału i wszystkim, co związane z efektywną kreatywnością.
lifedev.net.
Polecam uważać, bo wciąga niesamowicie.
W szczególności programistom przyda się uzupełnienie do wykładu Marcina Brodziaka w Instytucie Informatyki z 31 marca 2010.
lifedev.net.
Polecam uważać, bo wciąga niesamowicie.
W szczególności programistom przyda się uzupełnienie do wykładu Marcina Brodziaka w Instytucie Informatyki z 31 marca 2010.
Subscribe to:
Posts (Atom)