Marco Valtas

The study of or a collection of techniques.

Can you tweet a happy number function?

By Marco Valtas on August 11, 2010

After my last post on happy numbers, fellow ThoughtWorkers here in Brazil’s office started to come up with different languages implementations of the Happy Number function and the challenge was “Can you tweet that?”, here’s the results (not all are “tweetable”, but are pretty cool):

Thiago Nunes got a AWK(after a update the old version of 104 got reduced to 82):

{n=7;while(!(n in d)){d[n]=n;split(n,g,//);n=0;for(i in g){n+=g[i]^2}}print n==1}

length: 82 characters.

Sam Tardif, made a very short Python version:

import sys
d=sys.argv[1]
while d>9:d=sum(int(i)**2 for i in “%s”%d)
print’un’*(d!=1)+’happy’

length: 105 characters.

Here’s the shortest I’ve could make work in Perl:

perl -MList::Util=sum -e'$_=pop;until(/^1$/|$_{$_}++){$_=sum map$_**2,split//}print$_^1?"Un":"","Happy";' 7

length: 108 characters.

Impressive, Filipe Sabella wrote a Scala version:

scala -e 'var i=7;var s=Set(0);while(i!=1&& !s.contains(i)){s+=i;i=(""+i).map(a=>(a+"").toInt).map(n=>n*n).sum};println(i==1)'

length: 127 characters.

Thiago Marano’s Ruby solution:

ruby -e 'i=ARGV[0].to_i;a={};until(i==1||a[i]);a[i]=1;i=i.to_s.split(//).inject(0){|s,c|s+c.to_i**2};end;p (i==1?"":"un")+"happy"' 7

length: 133 characters.

Caio Kinzel did a Haskell version…

import Data.Char h x m=case(x,any(==x)m)of(1,_)->1;(_,True)->0;(_,_)->(h(sum$map(^2)$map(digitToInt)$show x))(x:m)
main=print$h 7 []

length: 133 characters.

Luiza Pagliari made one in R:

R -e “j=7;c=0;while(j!=1&is.na(c[j])){c[j]=1;j=sum(sapply(strsplit(as.character(j),”),as.numeric)^2)};
cat(ifelse(j==1,”,’un’),’happy’,sep=”)”

length: 160 characters.

Luiz Ribeiro took the time to do it in Prolog:

s(X,Y):-X<10,Y is X*X. s(X,Y):-I is X mod 10,J is I*I,K is X//10,s(K,L),Y is J+L. h(N):-h(N,[]). h(1,_). h(N,L):-not(member(N,L)),append([N],L,M),s(N,P),!,h(P,M).

length: 166 characters.

I did the most nasty tricks I knew in Java to get this one, but I don’t think is possible to cut 60 chars of it.

import java.util.*;class h{static{Set s=new HashSet();int e=7;while((e=c(e))!=1&&s.add(e));System.out.print(c(e)==1);}static int c(int o){int m=0;for(char d:(""+o).toCharArray())m+=(o=d-'0')*o;return m;}}

length: 205 characters.

Eduardo Radanovitsck did a C++ solution:

#include <iostream>
#include <set>
using namespace std;set<int> s;int i,a;int main(){cin>>i;while(i-1){a=i;i=0;while(a){i+=(a%10)*(a%10);a/=10;}if(!s.insert(i).second&&i){cout<<"un";goto l;}}l:cout<<"happy"<<endl;}

length: 216 characters.

Caio Kinzel (again) did a F#:

let s x=x.ToString().ToList()|>Seq.map(fun x->(int)(x.ToString()))|>Seq.map(fun x->x*x)|>Seq.sum
let rec h x m=match x,(m|>Seq.exists((=)x))with|1,_->1|_,true->0|_->(h(s x)(x::m))
printfn"%i"(h 5 [])

length: 220 characters.

People are still creating other languages implementations I will add more later. You’re invited to shorten the current ones or create new ones in new languages.

Posted in Programming | Tagged awk, c++, fsharp, happy, haskell, java, number, perl, prolog, python, R, ruby, scala | 16 Responses

Java & Ruby Happy Numbers

By Marco Valtas on August 8, 2010

Today I was doing what ThoughtWorkers do in their spare time and got puzzled, so I decided to share this with you. If you don’t know there’s a web site called Programming Praxis that posts little riddles (mostly numeric ones) to be solved in any programming language. I was implementing the solution for Happy Numbers and something strange happened, first let’s see my Ruby solution:

class Happy

  def initialize
    @seen = {}
  end

  def is_happy?(number)
    sum = sum_square number
    if(@seen.has_key?(1))
      initialize
      return true
    elsif(@seen.has_key?(sum))
      initialize
      return false
    else
      @seen[sum] = true
      is_happy?(sum)
    end
  end

  private
  def sum_square(number)
    sum = 0
    number.to_s.split(//).each do |d|
      sum += d.to_i ** 2
    end
    return sum
  end
end

Probably this is a naive solution (I’m not a Ruby developer) but did the job, tests worked and we are good. After that I’ve started implement the same solution in Java and here we go (please note the line 31):

package com.marcovaltas.happy;

import java.util.HashSet;
import java.util.Set;

public class HappyNumber {
	private Set<Integer> seen = new HashSet<Integer>();

	private int sumSquare(int number) {
		char[] digits = String.valueOf(number).toCharArray();
		int sum = 0;
		for (char d : digits) {
			sum += (int) Math.pow(Double.parseDouble(String.valueOf(d)), 2.0);
		}
		return sum;
	}

	public boolean isHappy(int number) {
		int sum = sumSquare(number);

		if (sum == 1) {
			initHash();
			return true;
		} else if (seen.contains(sum)) {
			initHash();
			return false;
		} else {
			seen.add(sum);
			isHappy(sum);
		}
		return false;
	}

	private void initHash() {
		seen = new HashSet<Integer>();
	}
}

Line 31 on the Java solution was added because the Java compiler was complaining about the possibility of this method not return, I’ve even tweeted that. So guess what happened? Didn’t work, the tests didn’t pass when I was “Uh?!”. Can you answer why? Take your time.

Answer

I’ve started to debugging and turns out that my tweet was totally wrong. The Java compiler was right and I needed that return, the only thing is that was in the wrong place. Let’s see the debugging session, if you want to try it download the code here, you can use Mercurial to download the code.

For the debugging I’ve used the number 7, and had a break point on line 19. So, as expected, the after the first call sum will have the value 49. The algorithm will proceed correctly until sum reach 1, then it gets interesting. Now sum == 1, so the code enters the if clause and reaches the return true; statement.

		int sum = sumSquare(number);

		if (sum == 1) {
			initHash();
			return true;
		} else if (seen.contains(sum)) {
			initHash();
			return false;
		} else {
			seen.add(sum);
			isHappy(sum);
		}
		return false;

So, what you expect to occur next? Probably, if not aware of what it happening, you will guess that the method returns. No, the call jumps to line 29.

		int sum = sumSquare(number);

		if (sum == 1) {
			initHash();
			return true;
		} else if (seen.contains(sum)) {
			initHash();
			return false;
		} else {
			seen.add(sum);
			isHappy(sum);
		}
		return false;

And then to line 31!

		int sum = sumSquare(number);

		if (sum == 1) {
			initHash();
			return true;
		} else if (seen.contains(sum)) {
			initHash();
			return false;
		} else {
			seen.add(sum);
			isHappy(sum);
		}
		return false;

After that, back to line 29, 31, 29, 31, 29, 31, 29 and finally 31, then returns false. So, why this happened? At, first I did some obscure analysis on the Java Language Specification and the book Ruby Programming Language comparing the return statements. But, as all things in life, there was a simpler explanation pointed out by Pavol Bernhauser and Luiz Ribeiro (a fellow TWer) on this blog comments. In fact still is a difference on specification, but a simpler one. For Java the value of returned from a method will be explicit informed by the return clause. So, if you follow the execution path here what is happening.

When we reach the first return true; (line 23), the control is handled back to isHappy(sum); call, the execution proceed to the next return false; (line 31), since we were in a recursion the return will handle back to the previous call of isHappy(sum); and this repeats through all intermediate numbers that made 7 a happy number (49, 97, 130 and 10). If you run on a debugger you will see the stack piling up.

The correct solution is make the call to isHappy(sum); a return call:

		int sum = sumSquare(number);

		if (sum == 1) {
			initHash();
			return true;
		} else if (seen.contains(sum)) {
			initHash();
			return false;
		} else {
			seen.add(sum);
			return isHappy(sum);
		}

But why the Ruby version worked? Well, as pointed out by Pavol and Luiz, it worked “because Ruby returns the result of last invoked statement as the result of method.” in this case the is_happy? was the last statement and so will be the result. If I did the same thing I did in Java, putting a return false; on the end the Ruby version will not work too. In this case it will follow the same steps that Java took I guess.

So, in the end, was a little difference with the languages specifications, the Java compiler was right, and I, as new to Ruby, got puzzled why the Ruby version worked. Living, coding and learning.

That’s it.

Posted in Java, Programming, Ruby | Tagged happy, java, number, ruby, specification | 4 Responses

Not all was lost…

By Marco Valtas on August 5, 2010

Today I got news about one fix we did, “We have to revert your changes, there’s a new scenario we didn’t know about.”. This wasn’t cool but happens on large businesses, as consultants we have to deal with it. But I was thinking about it and I remembered that we, even removing the feature, improved the code.

At first the code was static and without tests, as a ThoughtWorker would be a sin try to change the code without testing it. So we spent almost half of the iteration trying to find a way to test the code, after while and some refactoring we got some tests and then we started code the new feature, in fact, the feature was just a small piece of code (7 lines of code).

Now I had to revert the feature, but guess what, the feature has only 7 lines, the testing and the refactoring didn’t need to be reverted. So, even having to go back on the “visible” value we added, still we left value on the code base, not all was lost. Things like this happen when you’re in consulting, but keep in mind that good practices will always deliver value. Bas practices, specially in this case, will not.

Posted in Programming | Tagged consulting, refactoring, software | Leave a response

Agile missing gear

By Marco Valtas on July 13, 2010

Usually I learn things about what I do and how I work when talking to non technical people, yesterday wasn’t different. Trying to explain a little about Agile and why we do things this way I realized that sometimes there’s a missing gear on this machine.

Agile is a way to think about software development and maybe other things too, we organize ourselves in a process to deal with the undeniable truth “Things change.”. Agile is not a mystery, just realize that things will change and you will come up with some process to help you on that. Of course people already came up with some methodologies and tools, you can use it or adapt yourself  to your reality, nothing is written in stone, specially if you know that things will change in near future.

From the methodology/organizational way, usually we try give clients room to change things. Clients have to have something in hand to realize what they want, what is the priority of things and other issues. We keep our cycles small so we interact more often, get the most updated information and delivery what is expected. Communicate often, be open to change and development will be headed to the same direction of your client expectation.

Small cycles means a lot more commitment, as a team, we keep close eye on what we are doing, how long it takes, the problems, the pace and so on. Some people when see pictures like this thinks that Agile is just fun and no work, beware this fallacy. Agile is a very committed way of work and think. We don’t hide problems, tasks or how we feel on how things went. Exposing all of this make an Agile team vigilant and always visible to the client. The client, in fact has a major role in Agile but sometimes it seems it is the only gear that is missing.

Agile goes with the motto “Client, we will interact with you often, we want you prioritize,  as soon you change your mind please tell us, we want you to share your time with us…”. What I see is that sometimes clients get this wrong, more like “I can change things anytime and have update reports every day.” , this is not the right way to think.

Commitment is a two way street, if the team is committed, the client should be committed in the same degree. Surely we try to cope with change but this doesn’t mean that the client shouldn’t put enough thought on requests. We communicate often but this doesn’t mean we are reporting only, we’re in fact sharing and asking for information. We want deliver value, but this value will result of a sum of commitments. As in any relationship the two parts have to make an effort to make it work, is just not possible do it just from one side.

If someone is selling “We do Agile, tells us what you need, sit and watch your product going live.”, this is unlikely to be true. Agile can deliver faster and better but know that this machine is very weak if is missing a gear, the client.

Posted in Collaboration | Tagged agile | Leave a response

A DBA on your Project?

By Marco Valtas on July 2, 2010

Developers usually have some problems with databases, no news. Databases are complex tools, and that’s why we have people specialized in such tools, we call them DBAs (Database Administrators). When I did my course on Oracle Database Administration the instructor always emphasized that the DBA duty is “to keep the database available, even after a disaster”.  Its a fair statement, databases have to keep the data available, if not, most applications will just stop working.

Grow the environment to hundreds of developers, dozens of projects, legacy and new stuff been done. What happen? The databases turn into a thing too complex do deal with it. DBAs, have to keep a close eye on it, knowing if a new functionality can be hosted without break old one,  making the old data perform better for the grow of data and always with backup strategies in mind. I agree that’s a plenty of stuff to worry about and you should definitely keep DBAs looking into that. But what follows from that is a more and more complex database environment. Now the DBAs have more and more work to do while they are asked to tweak the database for this and for that.

The problem starts when, on a complex structure, you put developers coding new stuff in one side and DBAs are in other side. Developers have too access the data some way but they not aware of whole structure of the database, DBAs on the other side are not aware of the new stuff that is been developed. The direct consequence is a immediate problem in communication, one doesn’t know what the other is trying to achieve, and in this scenario usually they communicate too late. In software development, and most areas, communication problems is something you want to avoid. Having late communication makes the solution usually not optimal and takes more time.

What I think that could mitigate this is assign a DBA for each new project. The DBA doesn’t need to be exclusive for a project but should participate of stand up meetings, retrospectives, know about the stories been developed,  have the context of the project in general and be available for developers to answer questions, even pairing if the developer is coding an access layer. Meanwhile, the DBA group should exchange information about the projects explaining what changes are coming, how to prepare the data structure to accommodate better queries and how share the knowledge  to developers about the data and how is stored.

Obviously the main task of the DBAs (keep the system available) is still the most important, but you should have a core group working on that and others sharing time with development projects, than rotate the team from time to time. This probably will increase the number hired DBAs but the benefit, I think, will pay itself in productivity and maintenance cost. As we say in Agile “If it hurts, do it more often.”.

Posted in Collaboration | Tagged dba, project | Leave a response

Software Philosophy – Testing is about induction

By Marco Valtas on June 17, 2010

Testing software has some constraints, still is the best approach nowadays. Others have argued on mathematical proving of software, but this is costly and very hard to achieve. Yet, software quality is important. To understand why tests can’t guarantee that your software is “bug free” but still important let’s look at them from a philosophical point of view.

Inductive reasoning is a type of argumentation, the difference with deductive reasoning is in the former is possible for all premises be true and the conclusion false. This doesn’t happen with deductive reasoning.

Inductive reasoning can be Strong or Weak, here some simple examples:

A strong induction:

  • Every day the Sun rises.
  • Therefore the Sun will rise tomorrow.

A weak induction:

  • Every Friday morning a see John walking his dog.
  • Therefore tomorrow I’ll see John walking his dog.

You can see looking at these arguments that there’s a believe playing a role here. Both arguments have premises that are true, nevertheless something could happen and make the conclusion false. Nothing prohibits that John’s get sick and not walk the dog tomorrow or the Sun could just explode and disappear and will not rise anymore. The likeness of these outcomes is making them strong or weak. How this relate to testing? Let’s look on a simple example, first a simple class called Person and this class knows how to abbreviate it’s own name:

package com.marcovaltas.phi.testing;

public class Person {

private final String name;

public Person(String name) {
    if(name == null || name.isEmpty())
        throw new IllegalArgumentException("Person can't have a null name.");
    this.name = name;
}

public String abbreviateName() {
    String[] parts = this.name.split(" ");
    StringBuilder abbr = new StringBuilder();
    abbr.append(parts[parts.length - 1] + ", ");
    for(int i = 0; i < parts.length - 1; i++)
        abbr.append(parts[i].substring(0,1).toUpperCase());
    return abbr.toString();
}

}

In this case, a Person has to have a name, it cannot be created without one, and can abbreviate it’s own name. Now the tests:

package com.marcovaltas.phi.testing;

import static org.junit.Assert.*;
import org.junit.Test;

public class PersonTest {
    @Test
    public void personCanBeCreateWithName() {
        new Person("Marco Valtas");
    }
    @Test(expected=IllegalArgumentException.class)
    public void personCannotBeCreatedWithNullName() {
        new Person(null);
    }
    @Test(expected=IllegalArgumentException.class)
    public void personCannotBeCreatedWithEmptyName() {
        new Person("");
    }
    @Test
    public void personKnowsHowToAbbreviateName() {
        assertEquals("Cunha, MAV", new Person("Marco Aurelio Valtas Cunha").abbreviateName());
        assertEquals("Moreira, RC", new Person("Raquel Capistrano Moreira").abbreviateName());
    }
}

What role is tests playing in here? Well, they’re given us reasons to believe that Person behaves like we need to. In fact, we know that will be not possible to test every name in the world, but we try to make enough cases that will make more likely that the abbreviation algorithm is right.

Induction, like Hume wrote, bases itself on the “Principle of Uniformity of Nature”, or more loosely, that some things tend to behave like they did in the past (like the laws of physics), but still induction has problems.

In the code above, despite the tests, we are assuming that the Java language will behave like did before and that the standard libraries will too. But nothing prohibits that there’s a bug on the String class or even JUnit could have bugs. The “Principle of Uniformity” here is all environment we’re using that we can’t control, we’re assuming that it will be correct, which sometimes is not the case.

As the systems get bigger and complex more and more our tests are playing the role of making us believe that the system is correct. A code without tests seems like a conclusion without premises, it states something, but without much reasons for us to believe that it’s correct.

For the question of “How many tests should we write?”, there’s no right answer other than “Enough to make it a strong induction that the software is correct.”. To make a inductive argument strong you basically need:

  1. A reasonable sample.
  2. A unbiased sample.
  3. The conclusion should be relevant to the premises.

The first two are fairly clear, everyone that has some knowledge about statistics knows that sampling is an important part of a good research. The last one is more subtle, the linkage from the premises to the conclusion is very important too, there’s a old joke about “The Sun rises everyday, therefore I will fly tomorrow.”, very unlikely despite the premise.

In software testing the linkage is given by the use of the code that is tested. If the tests try to validate a class but doesn’t use the class in any way, probably we have a weak link. I believe that coverage metrics measures this linkage. For reasonable sampling, we need to provide enough possible inputs, values and situations. If we’re making an abbreviation algorithm maybe is a good idea to grab some names on a public list. Lastly, the unbiased sample. Tests can be written by the same programmer who wrote the code, but is possible that the knowledge of how the code was written will bias the programmer, pairing and QAs can mitigate this problem.

So, is not a question of “How many tests?” and, unless you have total control over all variables in your environment, is not possible to guarantee that your code is “bug free”, specially in complex systems. Still, testing is the better way to gain the confidence that your software is correct, and like another things in programming, there’s no final answer.

Posted in Misc, Programming | Tagged deduction, induction, java, philosophy, software, tests | Leave a response

Guide to Brazilians moving to Porto Alegre

By Marco Valtas on May 3, 2010

This post is written in Portuguese cause is only for Brazilians:

Foi aprovado na seleção da ThoughtWorks e está se mudando para Porto Alegre? Não tem referências ou família no Sul? Eis algumas informações para lhe ajudar, este guia foi criado para ajudar outros ThoughtWorkers, mas pode ser útil para qualquer um que venha para cá. Se houver mais informações que deveriam constar aqui basta comentar.

Nova Lei do Inquilinato

Talvez você tenha ouvido falar desta nova Lei, eis algumas notas sobre ela e suas consequências. A nova lei do inquilinato após publicada foi divulgada como um instrumento que iria facilitar a vida de inquilinos e proprietário, diminuindo prazos para remoção de não pagadores e afins, no entanto apesar dos novos mecanismos, as imobiliárias ainda trabalham com garantias altas (fiador com dois imóveis quitados) e acabam dificultando a vida de quem quer alugar uma casa ou apartamento. Mais informações nos links abaixo:

  • http://www.administradores.com.br/informe-se/informativo/a-nova-lei-do-inquilinato/28681/
  • https://www.planalto.gov.br/ccivil_03/_ato2007-2010/2009/lei/l12112.htm


Algumas Imobiliárias de Porto Alegre

Na maioria das imobiliárias você pode entrar no site e realizar buscas por casas e apartamentos, se não encontrar algo, procure ligar e informar o que está procurando.

  • Sperinde (http://www.sperinde.com)
  • Azenha (http://www.azenha.com.br)
  • Guarida (http://www.guarida.com.br)
  • Crédito Real (http://www.creditoreal.com.br)
  • Auxiliadora Predial (http://www.auxiliadorapredial.com.br)

Outros sites para buscar imóveis:

  • Hagah (http://www.hagah.com.br/rs/)
  • Tá Tri (http://imoveis.tatri.com.br/)
  • Busca Imóveis (http://www.buscaimoveis.com/pn/)

Outras maneiras de se encontrar imóveis

Se você já está em POA (Porto Alegre), pode olhar nos classificados de domingo do jornal Zero Hora (um jornal local) lá constam imóveis que não são publicados on-line. Mais uma sugestão é pedir a um Taxista para passar nos bairros (como o táxi não é caro em POA) e lhe ajudar a encontrar um lugar.

Garantias aceitas pelas imobiliárias

  • Fiador

Parece consenso entre as imobiliárias que devem ser dados dois imóveis quitados (algumas não aceitam terrenos) como garantia. Você pode utilizar dois fiadores cada um com seu imóvel ou um único fiador com dois imóveis. Algumas imobiliárias aceitam fiadores de outros estados mas você pode encontrar imobiliárias que não aceitam. Para quem está mudando de outro estado isso pode ser um problema.

  • Depósito

Neste caso você deposita um valor equivalente a 12 aluguéis (algumas imobiliárias exigem aluguel mais as taxas de condomínio e IPTU) numa conta. Este dinheiro irá render pela poupança e fica congelado enquanto você ocupar o imóvel. Provavelmente é a maneira menos burocrática de conseguir a aprovação, mas com certeza é a mais cara.

  • Seguro Fiança

Isso implica a utilização de uma seguradora, como Porto Seguro, Sul América e cia. A imobiliária irá indicar qual deve ser utilizada e o valor pode variar de 2 vezes o aluguel até 4 vezes o aluguel. Este valor geralmente poderá ser parcelado em até 4 vezes e deverá ser pago todo ano no aniversário do contrato.

Documentação:

Os documentos necessários variam de acordo com a garantia que você irá trabalhar, mas é bom ter em mãos:

Carteira Profissional – Preferencialmente já assinada pela ToughtWorks (ou pela empresa que você vai trabalhar), se você não tiver com ela por algum motivo, digitalize as páginas de identificação, últimos (os últimos dois) empregos e atualização salarial.

Comprovante de Residência – Mesmo que seja de outro estado mantenha consigo algum comprovante.

Comprovante de Renda (holerite) – Os três últimos pelo menos, caso você tenha trabalhado como PJ procure obter os extratos bancários dos últimos três meses. Se você possui um renda proveniente de um imóvel alugado é necessário o Documento de Propriedade do imóvel, Contrato de Locação e também o recibo do último aluguel.

Declaração do Importo de Renda – Após a entrega do IRPF imprima uma cópia da declaração completa.

RG e CPF – Você certamente precisará de cópias destes documentos.

  • Outros documentos:

Se você morava de aluguel talvez seja necessário informações sobre a Imobiliária responsável ou o contato do proprietário do imóvel. Talvez um declaração da imobiliária da isenção de débitos pendentes.

Claramente são muitos documentos e nem todos são necessários para todas imobiliárias, procure informar-se com a imobiliária previamente.

Deslocando-se em Porto Alegre

Porto Alegre é uma grande cidade, e as vezes o tráfego congestionar um pouco, mas nada parecido com São Paulo ou Rio de Janeiro, normalmente 20 minutos são suficientes para deslocar-se de carro no dia-a-dia.

  • Táxis

São suficientes, você encontra pontos em vários locais e basta esperar em alguma avenida que em poucos minutos é possível encontrar um e as tarifas não são caras. Eis uma ferramenta para calcular as tarifas:

http://www.tarifadetaxi.com/porto-alegre

  • Ônibus e Lotações

Há em Porto Alegre ônibus e lotações, as lotações são mais caras mas geralmente mais rápidas. Abaixo um link para um mapa com as linhas de ônibus:

http://lproweb.procempa.com.br/pmpa/prefpoa/eptc/usu_doc/mapa_linhas.pdf

Onde ficar

  • Hotel Ornatus – Um hotel simples, localizado no centro, diárias de 79 reais e com wi-fi. Basta pegar a Lotação PINHEIRO/PARTENON na ida e na volta.
  • Hotel de trânsito do Clube Farrapos – Fica pertinho da PUC (dá para ir a pé).

Bairros

Eis uma lista de alguns bairros de Porto Alegre, não é uma lista completa mas deve ajudar a escolher um lugar para morar, tentei separar em três categorias mas lembre-se que esta lista é apenas para dar uma ideia.

  • Alto Padrão

Bela Vista, Boa Vista, Moinhos de Vento,

  • Bons para morar (Mais próximos a PUC ou não muito caros)

Petrópolis, Auxiliadora, Bela Vista, Higienópolis, Cidade Baixa, Azenha, Menino Deus, Teresópolis, Jardim Lindoia, Jardim Botânico, Partenon

  • Evitar (Afastados ou inseguros)

Ponta Grossa, Hípica, Ipanema, Guarujá, Restinga, Agronomia, Centro, Zona Sul (em geral é afastada).

PUC-RS

A PUC-RS é suficientemente grande, possui restaurantes, caixas eletrônicos, agência bancária do HSBC, correios e etc. Mais informações siga o link:

Getting to Know PUC-RS

Cartórios

Eis uma lista no google maps de cartórios em Porto Alegre:

Google Maps

UPDATES:

  • (03/05/2010) Fixed some links and added Roger tips.
  • (04/05/2010) Added Hotel Information.

Posted in Misc | Tagged alegre, office, porto, thoughtworks | 6 Responses

First post as a ThoughtWorker

By Marco Valtas on April 29, 2010

I’m now at ThoughtWorks Brazil and after almost two weeks I feel that I need blog about it.

First thing that comes to mind is about agile methods. Some people think that having post-its all over the walls and toys make you less serious about your work. In fact, as many already stated, is the opposite. Daily stand-ups, progress glued on the walls and no cubicles makes you more and more engaged.

Something very different about ThoughtWorks is openness, most organizations I’ve worked state that they are open, but in TW this matter is taken seriously. Sure, there things that are confidential but not things that makes you uncomfortable. I remember in former jobs people closing the notebook lid when you come closer, whispering right in front of you and treating you like you are not part of the team. In ThoughtWorks you don’t fell that way, this is great, silly speculations probably will not last much, as the real information flows everybody has a real picture of the concerns, objectives and etc. No food for people given to gossip.

I’m still having training and not formally assigned to a project, but as far I can see now, it’s gonna be great.

Posted in Misc | Tagged thoughtworks, twbr, workplace | Leave a response

Managing Geeks

By Marco Valtas on September 20, 2009

I just read this blogpost from Patrick Kua which will lead you to this. As Patrick I don’t agree with all, but some points got my attention.

  • Geeks are trained in logic and ordered thought.

With these skills you can’t make BS decisions, if does not make sense they will detect it easily. When your IT resists to some business decision, is better check out what is happening, they can function as compass against illogic paths.

  • Respect is money

In the IT world respect is money. Note that all open source projects work this way. You can’t earn respect with nice talk, smiles or other common social weapons. IT guys will respect those who knows what they are talking about and are humble for those things they don’t know.
Respect is earned with work, good work and team work. Force will just make them shut and let you, or your project, drawn alone. With respect they will follow you, work late and keep you project the best as they can.

  • IT can’t fake work

This was something I never notice but, IT can’t fake work (in general). So, anything that sounds like fake you be detected and can’t be done at all. Usually other departments (who asked for the impossible) will throw stones on IT, telling that they are slowing the project. In fact, when I saw this, the root cause was a project without value, something to cover incompetence or IT is full and can’t deliver at the velocity asked. Is a good thing check what has been asked to IT. In my experience, IT will prioritize by it self. They will not respect illogic priorities and the will organize as they see the business plan. It’s very important to make it clear for IT where your business plan is pointed to, if you do, they will take care of projects that point in the same direction.

  • Conclusion

Well, these are just observations I made through the my years in IT. IT is a very important staff, usually they can spot problems very fast and a good understanding of the minds of IT is a good tool to lead your business to success.

Posted in Collaboration | Tagged geek, itil, managing | Leave a response

Software Philosophy – Refactoring Paradox

By Marco Valtas on September 16, 2009

Another day I was talking with a colleague about the Interpreter Pattern to solve a implicit language problem. Martin Fowler describes a pattern called Query Object to solve this, which is a interpreter focused on database queries.

Refactoring as the best technique

Code Refactoring is, after learn a language, is the most important thing a developer should know. Refactoring is what really reveals what soft means in software. When building a bridge is practically a one shot, once the foundations are ready you can´t improve them as the construction continues. But with software, you usually improve the foundations as you go, mostly because nobody knows where is the other side of the bridge you are building.

Refactoring paradox

Refactoring has a implicit paradox, you have to factor before refactor. You can’t, at first, use such good technique without make mistakes a priori. This fact became clear when we had to refactor a code which was growing to cope with combinations of SQL queries. In the book Refactoring to Patterns this problem is described as Replace Implicit Language with Interpreter.

But if you think about it you have to code the queries and many methods to see what implicit language is taking form. Probably you will not foresee the language, if you try to predict such implicit language many anti-patterns and bad practices will rise, such as Premature Optimization, YAGNI and etc. For this particularly problem, if you try to code the solution at first, you will end with a criteria object and without any value from your code since this generic approach already exists.

Frederick Brooks in the Mythical Man-Month wrote about the Pilot System. This idea implies the construction of a throw-away when coding a new system. He argues that if you not plan you will throw-away anyway. This idea agree with the refactoring paradox, you can´t refactor before factor and there´s no need for refactoring a good code, but the chances to get it right on the first try is minimal, I will make a bold statement that is impossible to get it right on the first try.

Conclusions

  • Brooks is right, plan to a throw-away, you will anyway, at least part of the code will be replaced.
  • Don’t fear rewriting, is part of the job, put it on your estimates.
  • Software is soft don’t try to make it hard, is unnatural.

That’s it.

Posted in Programming | Tagged brooks, development, methodology, refactoring, software | Leave a response

Search Posts

Pages

  • About me
Next »

Copyright © 2010 Marco Valtas.

Powered by WordPress and Hybrid.