Benvolguts companys, ja s'acosta el dia del primer workshop.
El feedback que he tingut fins a dia d'avui ha sigut molt engrescador a nivell personal però poc encoratjador pel que fa a la realitat (en resum, poca gent apuntada).
Al ser la primera edició dels cursos, prioritzo el fet de tenir la classe plena, ja que m'interessa molt saber la opinió de la gent. Com que ja que casi tinc els materials preparats, he decidit fer un descompte i oferir el pack sencer per 250 euros en comptes de 330.
Aquest descompte aplica de forma retro-activa a la gent ja apuntada i és només aplicable a la primera edició dels workshops.
D'altra banda, he intentat - i encara ho estic fent - habilitar els cursos perquè es puguin fer subvencionats amb les beques de la fundació tripartita. Intentaré que de cara a una propera edició que aquest tema ja estigui resolt.
Finalment, us deixo aquí (link) el contingut d'unes diapositives del workshop de patrons de disseny pels que tinguin curiositat o encara no es facin una idea de quin serà el format del curs (penseu que hi ha diapos buides perquè es simplement serveixen per obrir una discussió o sessió de codificació).
Com sempre, qualsevol mena de feedback serà apreciat.
Salut,
Xavi
diumenge, 14 de setembre del 2014
dijous, 26 de juny del 2014
Hello world
Hi,
My name is Xavi Ametller Serrat and I try to think of myself as a programmer.I've spent most of my professional life working on C# and .Net. I started developing in WinForms and nowadays I´m transitioning to Asp.Net world. In between, I had a wonderful testing experience.
I had been in several projects which didn't meet the expectations - be it any combination of time, quality and cost - which just demonstrated me how unprepared I was (and am) for real world developing. In an effort to reduce my limitations, I went back to school and started to read programming books.
School didn't help me a lot, but I found an insane amount of invaluable knowledge in books. Amongst my personal bibles there are Design Patterns, Code Complete, Refactoring, Peopleware and several other books (what can I say? I like classics).
And... why a blog?
I enjoy explaining stuff and I find myself discussing the same topics every once in a while, so I decided to write it down. Hence yes: this blog is meant to be a pedagogical introduction to my own world of programming.
Welcome to myOwnCommonSense!
Xavi
dilluns, 26 de maig del 2014
Double negative
What does this mean?
No digit characters are rejected by NumericalValidator.
Even though the quite self-descriptive NumericalValidator class name, it is unclear if the validator accepts or rejects letters or digits. This sentence is hard to understand due to the double negation, which requests an unnecessary effort from the reader (as it has to inverse the content of the sentence twice to find out the real meaning).
In a nutshell, do not ever use double negative, it's misleading and error prone.
Another classical example
I do not disagree can be translated into I agree.
The exception
Apart of poetry, the only exception I can see to this rule is when you pretend to confuse your reader or whoever are you arguing with, then it can be used as a way to obscure the message (and without lying!).
I wouldn't recommend you to do so, discussions which need treats like those are usually unhealthy as they derive in who's best at using the language and rhetorics and not at what's the best solution to the subject being discussed.
The code!
Of course, all this dissertation also applies to your code! Avoid using the negation operator in front of variables whose name is negative (either contain not in the name or use a negative word).
For example:
!notClosed would be the same as !Open but less readable.
No digit characters are rejected by NumericalValidator.
Even though the quite self-descriptive NumericalValidator class name, it is unclear if the validator accepts or rejects letters or digits. This sentence is hard to understand due to the double negation, which requests an unnecessary effort from the reader (as it has to inverse the content of the sentence twice to find out the real meaning).
In a nutshell, do not ever use double negative, it's misleading and error prone.
Another classical example
I do not disagree can be translated into I agree.
The exception
Apart of poetry, the only exception I can see to this rule is when you pretend to confuse your reader or whoever are you arguing with, then it can be used as a way to obscure the message (and without lying!).
I wouldn't recommend you to do so, discussions which need treats like those are usually unhealthy as they derive in who's best at using the language and rhetorics and not at what's the best solution to the subject being discussed.
The code!
Of course, all this dissertation also applies to your code! Avoid using the negation operator in front of variables whose name is negative (either contain not in the name or use a negative word).
For example:
!notClosed would be the same as !Open but less readable.
dissabte, 24 de maig del 2014
Conditional breakpoint and cheatpoint
Conditional checkpoints are a practical and powerful tool. Premise is simple: you setup a condition and, while debugging, execution only stops if condition is met.
The key word here is condition, whose potential is sometimes underestimated even though the conditions input dialog is quite explicit about its options (sorry dialog pic is in Spanish):
So, a commonly missed feature is that breakpoint can stop in case a value has changed. I have no clue why people is missing this (me the first one). Maybe it's a usability problem (put the blame on them, as usual).
The second feature that is often missed it's a misuse of conditional breakpoints which I like to call conditional cheatpoints.
Think about a conditional break point as a function that is called and stops execution depending on its results. Give it an evil twist... and you have an open door for sloppy code injection! Whatever you state in the conditional break point condition will be executed every time execution flow reaches the line with the break point. BTW, credit for conditional cheatpoints for Jordi Rodriguez, who discovered them to me.
What the hell I am using conditional cheakpoints for?
When I work with slow to compile solutions and I make a mistake which prevents code to take the execution path I would like to test, sometimes I can add a cheatpoint to force code to take the execution path I want without having to stop execution and recompiling it.
Example:
In the following screenshot you can see that I set hasStock to true in the condition breakpoint. This way, even if HasStock method has a bug which returns false by mistake I can force the execution of the stock removal code.
dijous, 8 de maig del 2014
Guesstimate
Guesstimate is a fancy word to define a bold estimate, an estimate made without enough details, knowledge and/or time.
Real world application, when somebody (usually your boss) is pushing hard to get an estimation and doesn't accept the canonical answer (need time to think about it, can't answer without some previous checks, ....) and you finally dare to answer, then the answer must be clearly a guesstimate.
Hope you don't need it a lot!
Real world application, when somebody (usually your boss) is pushing hard to get an estimation and doesn't accept the canonical answer (need time to think about it, can't answer without some previous checks, ....) and you finally dare to answer, then the answer must be clearly a guesstimate.
Hope you don't need it a lot!
diumenge, 16 de febrer del 2014
Naming vars temp
Do not ever create a var called temp ... unless you have a very good reason (you know the consultant answer, "it always depends").
The name temp doesn't give any information at all about what it is contained in a variable. Ok, I went too far, it gives some information: durability of the variable, but still, nothing about what it will contain.
As the durability of a variable is something that comes implicitly with its scope, why don't we leave that responsibility to the scope? Otherwise, we just risk ourselves of being inconsistent (for example, creating a local variable called global or vice-versa).
As a typical example we´ll have the case of swapping values between variables:
Dirty:
Nicer:
Thanks to renaming all variables and parameters to have self-defining names, readability of the function has been improved (even though the function was so simple it wasn't really required). Anyway, rule sill applies to code of higher complexity, not to say in cases with several "temp" variables (seen them: temp1, temp2, ...).
The name temp doesn't give any information at all about what it is contained in a variable. Ok, I went too far, it gives some information: durability of the variable, but still, nothing about what it will contain.
As the durability of a variable is something that comes implicitly with its scope, why don't we leave that responsibility to the scope? Otherwise, we just risk ourselves of being inconsistent (for example, creating a local variable called global or vice-versa).
As a typical example we´ll have the case of swapping values between variables:
Dirty:
Nicer:
Thanks to renaming all variables and parameters to have self-defining names, readability of the function has been improved (even though the function was so simple it wasn't really required). Anyway, rule sill applies to code of higher complexity, not to say in cases with several "temp" variables (seen them: temp1, temp2, ...).
Subscriure's a:
Missatges (Atom)