The search for the PHP development environment

As someone involved with software development, I believe that the environment used should help you achieve your goal.   That means different things for each one but usually relates code completion, debugging, deploying and so on.

Working with development for web and using scripted languages since 1999 I’ve always had the feeling that we’ve lost something when abandoned the traditional target (the desktop).

That meant losing a debugger, using notepad (or vi) for code editing and having to create new frameworks from scratch.

Things got better over time as big players such as Sun (now Oracle) and Microsoft started   to foster an ecosystem that created IDEs, frameworks and debuggers to close the gap.

Working with open source solutions, like PHP, has some drawbacks in that sense because  there is no big player betting on it, nor a cohesive or predictive road plan.

Fortunately over time some companies, like Zend, stepped in and gave us a more “enterprise” solution in a form of it’s Zend Framework or the Zend Server Suite.  And that takes us to the subject at hand.

Mac OS : Nor windows nor Linux

Developing for web traditionally translates into hosting into Linux and developing under Linux as well.  The second option is Windows (due to the vast number of windows based desktops) and the third is Mac OS.

In my case I’ve switched from Linux/Windows to Mac OS X a while ago and had to deal with the fact that none of the solutions that I’ve learnt to use could be used as is.  Even tough it is an Unix based OS, the differences between Linux and BSD and Apple’s choices made some things specially difficult.

There was no “XAMP” like available and trying to compile everything from source was a challenge to say the least.

Zend Community Server 

Zend is one of the companies that have been created around the PHP and in the recent years they introduced a bundle called Zend Community Server (now simply Zend Server), that contains MySQL, apache, php and phpMyAdmin.

For me that was the perfect match between an enterprise focused distribution with the ease of use I was looking for.  With one click I had everything set and was good to go.

Unfortunately that didn’t last for long! :(

The recent versions incorporated a lot of features that promises to help the monitoring, deployment and debugging parts of your projects, but that came with a price higher than I was willing to pay.  Since all of those features are limited to the payed version, which is really targeted to medium-to-large shops I ended up with a more confusing, bloated version where almost all features are disabled.   And if you add on top of this the “second citizen” status of Mac OS for the support and the long time between updates I decided it was time to consider other options.

There and back again

Unfortunately I could not find a bundled solution that did not face the same issues for Mac.  My last resort was to go back to do-it-yourself, but this time instead of having to struggle to do it all manually I ended up using Homebrew for the heavy lifting and choosing a binary package for php.

This way I use the native apache that comes with the system and complement the rest with a setup time closer to the bundled version that I had.

Now I am back to having an up-to-date environment (PHP 5.5!) with minimum amount of time dedicated to set up and maintenance :)

Share
Posted in Desenvolvimento, Git, Mac OS X, PHP, Uncategorized | Leave a comment

Continuous Integration for Software Development

The software development scenario changed over the last years with the increasing participation of web based solutions as a replacement of the tradicional desktop applications.

In this scenario you usually don’t install the app, simply access it using a modern browser.  That solved some problems (and created others) such as the need to rely on the users to install the updates.   Now you simply update your app on the web server and in the next access your users will use it.

This led to a trend were the “release soon, release often” is adopted in an increasing rate. The major players have millions of users and manage to push, in a daily basis, new versions with corrected or new features.

To cope with this short release cycle some changes in the traditional development process occurred.  The usage of agile methodologies such as Scrum helped but the pressure to have a bug-free are still there.

As anyone involved in the development of software can tell you, manually testing all features quickly becomes impossible as your software grows and the release cycle shortens.   The same applies to the other relevant aspects, such as guaranteeing adherence to coding standards, detecting copy and paste and generating documentation.

In order to help us automate some os those tasks, tools and techniques like TDD/BDD were developed and have been increasingly adopted.

One particular tool that I’ll start discussing in this article is the CI (Continuous Integration) server as one important part of our development strategy.   If you search for the definition of CI you will find that it “is the practice, in software engineering, of merging all developer workspaces with a shared mainline several times a day”.

For our purposes the CI will be responsible for verifying if the software being developed works and meets the quality standards defined as part of the development process.  In its simplest form (and initial definition) the CI will periodically run the unit/system tests and report the result of current “build” of the software.

That alone is of great help because it allows the Q&A process to be part of the development as it occurs, and not after it has been finished.  And since it is an automated tool we can configure it, for example, to be run after every commit is made to our source code repository.

Before we start configuring our CI server let’s take a brief look on quality control of software development.   Unless stated otherwise all examples/tools will be based on PHP but the principle can be applied to other tools and languages as well.

Quality Control

Now that we know, albeit briefly, what is the job of a CI, let’s dig a little deeper and specify some of the tasks you may want to make it do it for you.

Testing

Every developer should develop code that is bug free and that performs exactly what we expect from it.  Unfortunately in reality a lot of factors prevent this from being something we can count on 100%.

So besides code review, the recommended approach is to either use TDD or at least develop unit and system tests to verify that the code being developed not only satisfies the specifications/user stories, but it also did not break anything else in the process.

Even tough each developer should run the entire test suite, sometimes it may not be feasible due to the time that the tests may take to run.

So in one situation or another the CI can help you by ensuring that the code that has been committed to, for example, the release branch, has all the tests run and a report generated.

You can add triggers so emails can be sent if the tests break, or even check the builds to see which commit caused the undesired behaviour.

Code Coverage

Code coverage is a metric that can be applied to your project that allows to mesure how much of your code has been executed by your tests.

Code coverage

In addition of having such percentage you can understand which tests are executing your code and which lines have or haven’t been called.

Code coverage details

The code coverage generation can be also automated by your CI server as it executes the unit tests.

Coding Standards

As a good practice, specially if you have more than one developer in the team, is to choose a coding standard.  That allows you some level of predictability of the created code.  Pear, Zend, PSR are some of the standards found in the PHP world that defines aspects as how to write the function names, usage of tabs, maximum line length and so on.

You can add a code sniffing tool, such as PHPCS, to be executed by the CI server as new commits are added so you notify the necessary parts when a violation occurs and where.

PHPCS2

Code duplication

One of the principles you should always try to follow is DRY (Dont Repeat Yourself), which means prevent or at least hunt down the duplicated code you have.

While some aspects still benefits from manual inspection, this is one that can be better executed by a tool like PHPcpd (Copy and paste detector), which scans the source code and points out which parts are copies.

PHPCPD

Code complexity

As time goes by and your project grows, one usual side effect is that adding new features start to take more and more time and/or are followed by breaking of existing functionality (aka regression).

While the usage of test driven development technique mitigates this or at least makes it apparent by failures in the test suite, you can almost point the code complexity as the culprit.

Spotting unnecessary complexity requires analysis of the source code and a certain degree of expertise since it is not always easy to detect where you have possible problems.   Tools like PHPDepend (inspired the the Java counterpart JDepend) can help you to perform static analysis and gather a toon of metrics.

It will be still up to you to decide what should be changed (and how) but at least you will have good starting points and a more precise way of measuring the result.

Among the several available metrics one that can indicate problems is the cyclomatic complexity.  With this metric you assign scores (and adds) as different execution paths appear in the code (if, switch, try/catch etc).

Cyclomatic

The higher the cyclomatic complexity, more difficult is your code to read and, by default, to change it or extend it.   As a matter of fact complex code usually triggers the copy and paste programming.

pyramid

Conclusion (not quite)

As we’ve seen you can do a lot in terms of quality control of your project.  The tools and metrics briefly shown in this post can be used standalone but beg to be automated so we can update them as the software is developed, and not only at the end (hence the continuous name).

In the next post I’ll start configuring one CI server (Jenkins) to make it gather all the artifacts shown and a few more for a sample project.

Share
Posted in Desenvolvimento, PHP, Uncategorized | Leave a comment

Instalando o Xdebug 2.1.2 no Mac OS X Lion e Zend Community Server 5.5

O Xdebug é uma ferramenta muito útil para avaliar o desempenho de programas e, como o nome diz, realizar o debug.

Em condições normais utilizariamos o pecl install xdebug mas no Mac isso gera problemas com a plataforma utilizada.

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/zend/lib/php_extensions/xdebug.so' - dlopen(/usr/local/zend/lib/php_extensions/xdebug.so, 9): no suitable image found.  Did find:
	/usr/local/zend/lib/php_extensions/xdebug.so: mach-o, but wrong architecture in Unknown on line 0

Temos então que realizar a compilação manual do Xdebug.

Siga os passos abaixo:
Faça o download dos fontes do xdebug

Extraia o pacote

Execute os comandos

MACOSX_DEPLOYMENT_TARGET=10.7
CFLAGS="-arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"
CCFLAGS="-arch i386 -arch x86_64 -g -Os -pipe"
CXXFLAGS="-arch i386 -arch x86_64 -g -Os -pipe"
LDFLAGS="-arch i386 -arch x86_64 -bind_at_load"
export CFLAGS CXXFLAGS LDFLAGS CCFLAGS MACOSX_DEPLOYMENT_TARGET

Use o phpize

/usr/local/zend/bin/phpize

Siga o processo de configura/make

./configure
make

Copie o xdebug.so (como root ou através do sudo)

cp modules/xdebug.so /usr/local/zend/lib/php_extensions

Desligue o debug padrão do Zend /usr/local/zend/etc/conf.d/debugger.ini (como root ou através do sudo)

; zend_extension_manager.dir.debugger=/usr/local/zend/lib/debugger

Ative o xdebug no começo do /usr/local/zend/etc/php.ini (como root ou através do sudo)

zend_extension = /usr/local/zend/lib/php_extensions/xdebug.so

Reinicie o apache (como root ou através do sudo)

/usr/local/zend/bin/zendctl.sh restart-apache
Share
Posted in Mac OS X, PHP | 1 Comment

Git : Usando o stash para salvar trabalhos em andamento

O git é uma ferramenta para controle de versão muito versátil.  Uma das funcionalidades que acho interessante e útil no dia-a-dia é o stash.

Imagine a seguinte situação, você está trabalhando em um branch em conjunto com outra pessoa e após ter feito algumas alterações você precisa revisar o que esta pessoa fez.

Seu trabalho ainda não está completo para merecer um commit e se você tentar fazer o pull irá ter problemas ou fazer o merge das suas mudanças com as dele.

O que fazer nesse caso?  Uma solução seria copiar seus arquivos para outro local e baixar os dele e depois restaurar os seus.

O git oferece a possibilidade de você armazenar, localmente, as versões in progress de seus arquivos para situações como estas.

Para tanto você deve usar o comando abaixo:

git stash save "mensagem"

Ao fazer isso você irá salvar os arquivos modificados e ainda não comitados para esta área reservada e associar a esta uma mensagem para lhe ajudar a saber o que estava fazendo.

Após este comando ele ira resetar todos os arquivos para a última versão comitada. Você pode fazer o pull ou demais operações e quando quiser retomar o que estava fazendo basta usar o comando

git stash apply stash@{0}

O stash funciona como uma pilha na qual é possível armazenar várias “versões” dos arquivos sendo editados. O comando anterior irá retornar a posição mais antiga (0) da pilha.

Se você quiser ver o que existe no stash use

git stash list

Para obter qualquer outro elemento você simplesmente identifica qual posição deseja obter no apply stash@{x}.

Para limpar a pilha (removendo todas as posições) use

git stash clear
Share
Posted in Desenvolvimento, Git | Tagged , | Leave a comment

Habilitando o mcrypt no ZendServer 5.5 / Mac OS X Lion

O Mac vem por padrão com  PHP e o Apache que já permitem o desenvolvimento de aplicativos em qualquer computador Apple.

Entretanto a Apple é notória por usar versões desatualizadas ou com poucas extensões e ainda demorar para liberar atualizações.   Por isso é comum que quem desenvolva no Mac usar distribuições de Apache+MySQL+PHP.

A que tenho usado e recomendo é a Zend Community Server, na sua versão 5.5.  Entretanto no Mac OS Lion a extensão do Mcrypt, usada para criptografia, que vem com ele não funciona.

Siga os passos abaixo para usar esta versão:

  1. Instale o Xcode – você precisará do compilado gcc e das bibliotecas para compilar a extensão.   Você pode instalar o Xcode pelo App Store
  2. Faça o download o libmcrypt em http://sourceforge.net/project/showfiles.php?group_id=87941
  3. Faça o download do fonte do php (neste caso 5.3.8) em http://www.php.net/downloads.php.  É importante que a versão do fonte seja a mesma da que é distribuida com o Zend Server
  4. Descompacte o libmcrypt e mude o diretório para ele
  5. Use o comando abaixo para configurar o fonte
    MACOSX_DEPLOYMENT_TARGET=10.7 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' ./configure --disable-dependency-tracking
  6. Compile o libmcrypt
    make -j6
  7. Instale o libmcrypt
    sudo make install
  8. Descompacte o php
  9. Mude o diretório para php-5.3.8/ext/mcrypt
  10. Use o comando abaixo para configurar a extensão
    MACOSX_DEPLOYMENT_TARGET=10.7 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' ./configure --with-php-config=/usr/local/zend/bin/php-config
  11. Compile a extensão
    make -j6
  12. Instale a extensão
    sudo cp modules/mcrypt.so /usr/local/zend/lib/php_extensions/
  13. Reinicie o servidor apache e você deve ver algo assim


Share
Posted in Desenvolvimento, Mac OS X, PHP | Tagged , | Leave a comment

Desenvolvimento de software : realidade e desafios

“Nova metodologia de desenvolvimento promete revolucionar a forma como desenvolvemos software”

“A nova versão do Ruby on Rails/C#/Java/node.js introduz funcionalidades que permitirão desenvolver mais rapidamente código”

Estes são dois exemplos de frases que encontro na mídia especializada quando o assunto é desenvolvimento.

Ao mesmo tempo o que encontro são reclamações de que os softwares que adquirimos (ou fabricamos) possuem de uma a três das características abaixo:

  1. Acima do prazo
  2. Acima do orçamento
  3. Não satisfaz às necessidades do usuário

Como alguém que possivelmente já desempenhou todos os papéis da cadeia de produção de software, de Cliente a tester passando por analista,  desenvolvedor e gerente de projeto tal realidade sempre me surpreendeu.

Enquanto Eu não acredite que exista (ou venha existir) a “bala de prata” para software, ou seja, a solução/linguagem/framework/metodologia que atenda a todos os tipos e peculiaridades do software, me assustam os dados que tratam que cerca de 90% do software produzido sofre dos três problemas citados anteriormente.

Em busca de um “por quê” venho estudando nos últimos anos os diversos aspectos envolvidos na produção de software.  Afinal se encontrarmos a causa fica mais fácil encontrar a solução, certo?

Apesar de considerar que ainda há muito espaço para avanços minha conclusão é que, infelizmente, estamos tratando de um problema sem solução. Ao citar isso quero dizer que a despeito de alguma solução verdadeiramente revolucionária (ou mágica) o melhor que podemos fazer é conter o caos que é inerente ao processo e mitigar o impacto dos três problemas venham causar.

Quando converso com um amigo que não é da área técnica Eu sempre escuto que ele não entende como podemos ter tantos problemas nessa área.  Eu tento explicar que apesar de estar englobada em uma área de ciências exatas o desenvolvimento de software já deixou de ser (se é que algum dia verdadeiramente foi) uma área determinística.

Idealmente deveríamos poder, passados 50 anos desde o aparecimento da computação chegar numa fórmula que nos permitisse dizer o que queremos que o software faça e termos uma resposta precisa sobre quanto tempo e quantos recursos ele necessitará.

Donald Knuth, professor de Stanford, escolheu para o título de seus livros o estranho nome de “The Art of Computer Programming”.   O que é estranho é que o termo arte, associado normalmente a criação, foi aplicado a algo que na sua definição não deveria necessitar de nenhuma criatividade.  Dado um problema existe um conjunto finito de soluções para resolvê-lo. Ou não?

Para explicar que motivos me levam a tomar esta decisão é preciso voltar um pouco no tempo e entender o caminho que percorremos até a realidade atual.

Com excessão dos primeiros computadores e seus respectivos programas que eram extremamente limitados, o desenvolvimento de software consistia em você pegar um problema do dia-a-dia, como uma folha de pagamento que precisava ser calculada manualmente, e modelava este problema usando alguma linguagem de desenvolvimento.

E aí se encontram as principais características que são as origens dos problemas:

a) Definição do problema/solução

Mesmo passados muitos anos ainda não temos uma maneira de especificar o problema e a solução de maneira a eliminar a ambiguidade ou possibilidade de interpretação diversa como existem em outras áreas.  Assim sendo uma mesma especificação de software tem uma margem que permite a interpretação diferenciada.

b) Complexidade x Abstração

A maioria dos problemas é suficientemente complexo quando se olha de perto.  Excessões, validações, cenários são variados e a combinação de variáveis é suficientemente grande para tornar o desenvolvimento impossível.

Para contornar essa realidade usamos em nosso dia-a-dia abstrações que visam simplificar o que estamos tentando entender ou resolver em termos mais contidos.  Infelizmente como efeito colateral das abstrações também escondemos detalhes relevantes a solução.

Com isso criamos soluções que funcionam em certas condições mas não em todas.

O que temos feito a esse respeito?

Em minha opinião nada que efetivamente produza resultados.  Basta acompanhar que o ritmo de linguagens e frameworks só aumenta em vez de diminuir.   Ou seja, continuamos a aumentar o caos já que com a quantidade de linguagens, plataformas existentes quem pode realmente se considerar um especialista?

O Java está na versão 7.0 e ainda contem problemas de compatibilidade e funcionamento que existem desde seu lançamento há mais de 15 anos.

Nos preocupamos em “avançar”, criando novas camadas de abstração sobre as que já existiam em vez de se concentrar em resolver problemas.

É por isso que não creio que vejamos uma real melhoria no quadro enquanto a realidade por trás dos problemas não for colocada como prioridade pela indústria.

Share
Posted in Desenvolvimento | Leave a comment

Perspectivas do mercado móvel em 2011 (2a parte)

No último post apresentei minha visão sobre os fatos que aconteceram e estariam para acontecer no mercado móvel.

Passados 6 meses que novidades temos neste setor?

Do ponto de vista estritamente tecnológico não há muito o que se comentar.  O iPad2 foi lançado com a mesma fanfarra que o anterior e finalmente adicionou um item que já era padrão nos demais tablets : câmeras.

Além do hardware melhor e mais fino a Apple conseguiu fazer de novo algo que sempre me intriga: apresentar features já existentes em outros dispositivos mas fazê-lo de maneira que todos (ou quase) esqueçam disso.

Os rumores agora são que o iPad3 seria liberado este ano juntamente com o iPhone5.  Até o momento não há confirmação de tal e pelas vendas do iPad2 eu particularmente acho que seria uma decisão equivocada.

Como os concorrentes não conseguem se aproximar da Apple mesmo tendo soluções de hardware superiores não vejo por que apressar o lançamento de uma nova versão. É melhor capitalizar sobre os ganhos de escala que o modelo corrente vem apresentando.

Recentemente a HP decidiu mandar sinais confusos para o mercado sobre sua estratégia quanto ao WebOS e a única certeza que temos é que ela está saindo do mercado de tablets.  Ou melhor, saindo por ora!

O Playbook da RIM e o Xoom da Motorola amargam vendas abaixo do esperado e o único concorrente que tem gerado algum volume de vendas é o Galaxy Tab 10.1.

Por enquanto nenhum dispositivo lançado comercialmente usa os modelos Quad-core da Nvidia (ou similar) mas a tendência é que tal seja inevitável em 2012.

A união da Nokia + Microsoft anunciada no início do ano ainda não apresentou resultados concretos mas deve fazê-lo nos próximos meses.  Resta saber se a Nokia ira matar todos os demais dispositivos para apostar no OS móvel da MS.

Num movimento recente o Google comprou a divisão de celulares da Motorola supostamente para ter um controle maior sobre todo o processo e acelerar ainda mais o uso do Android.  Vamos esperar para ver o que na prática isso resultará.

Share
Posted in Geral | Tagged , , , , , , | Leave a comment