Participações em eventos de 2011

O ano de 2011 está agitado para mim.

Já estive no JustJava, no The Developers Conference (edição São Paulo) e na próxima semana estarei presente no TDC Florianópolis. Em Setembro ainda tenho o QCon, evento do InfoQ-Caelum. E sobre o quê tenho falado? Apache Wicket.

O desenvolvimento Web em Java deixou de ser lento, e nestas minhas palestras, apresento uma proposta diferente. Programadores e Web Designers trabalhando em conjunto sem que um prejudique ao outro.

Foi-se o tempo que a separação de camadas se dava apenas na programação. Chegou a hora de separar também o trabalho do designer e o do programador. Afinal, o web designer é quem entende bem de CSS, efeitos, web fonts e UX.  No meu post "What are web frameworks missing?" detalho melhor este tema.

Mas voltando aos eventos, segue a programação para quem quiser saber mais:

The Developers Conference - edição Florianópolis
Data: 20 de Agosto de 2011 - 13:10 na trilha Java
saiba mais


QCon - São Paulo
Data: 10 de Setembro de 2011 - 18:10
saiba mais

E se quiser se aprofundar mais, confira o Curso de Apache Wicket que lancei este mês. O curso começa no dia 4 de Setembro.

Curso de Apache Wicket

Lancei ontem o Curso de Apache Wicket, para iniciantes e para aqueles que já utilizam. O curso será ministrado online através de uma ferramenta com compartilhamento de tela e chat. Serão ao todo 4 aulas com duração de 3 horas e meia.

Durante o curso, os alunos construirão uma aplicação completa, integrada ao Spring, paginação e outras funções em Ajax. Os interessados podem se inscrever pelo site www.cursodewicket.com.

Valor: R$ 389,00


4 de Setembro: 9:30 - 13:00
11 de Setembro: 9:30 - 13:00
18 de Setembro: 9:30 - 13:00
25 de Setembro: 9:30 - 13:00

Run Activity with Intent without knowing the class

I was having a problem this evening where I had to call an activity that I didn't want to know the class name. My problem was exactly this: I have several activities, each with a String id. And in activity A I call goToScreen("b"); to load activity B.

To make this work one need to do this:

public void goToScreen(String id) {
  PackageManager pm = androidContext.getPackageManager();
  Intent intent = new Intent("com.myproject.screen."
    + id.toUpperCase());
  intent.addCategory(Intent.CATEGORY_DEFAULT);

  ResolveInfo ri = pm.resolveActivity(intent,
    PackageManager.MATCH_DEFAULT_ONLY);

  if (ri != null) {
   Intent i = new Intent();
   i.setClassName(ri.activityInfo.applicationInfo.packageName,
     ri.activityInfo.name);
   androidContext.startActivity(i);
  }
 }

This code will call an activity mapped on AndroidManifest.xml like this:

<activity android:label="@string/app_name" android:name=".AvisoActivity">
   <intent-filter>
      <action android:name="com.myproject.screen.AVISO" />
      <category android:name="android.intent.category.DEFAULT" />
   </intent-filter>
</activity>


The DEFAULT category is not optional, as one may think. If you don't put both references (Java and XML) of the category, this code won't work. I don't know if it's a bug at Android or just a non-documented feature (which is a bug to me, anyway).

Also, don't forget to call resolveActivity with MATCH_DEFAULT_ONLY.

This is all for tonight and this blog post is more like of a reminder to myself. =)

Bug maldito

Bug maldito, bug maldito
Ajuda o sistema a travar
Nunca desiste, nunca descansa
Escondido!
Ainda vou ter que encontrar


original

What are web frameworks missing?

First of all: there's no perfect web framework. And it doesn't matter what technology, language or platform. But I finally have come to one thing that is really important. Something most web frameworks are missing, and something I believe, as many other developers that have already blogged about, is the future of the Web.

Let's start with the consequence of the problem: the infinit fight between Web Designers and Web Developers. Designers and developers have been fighting for years within web development. And this happens because the work done by designers usually is "destroyed" by developers when they have to inject dynamic/logical code into the HTML, converting it to something like JSP, PHP, RHTML or a mix of Python and HTML. It doesn't matter the language.

The problem is clear: what the designer did goes away. If he must update the design, even if the data structure won't change, most certainly you will have problems. He might break some logics, some code, and you will have to fix it. Then, you might also break some layouts and he will have to fix it. And you might go into a loop for a couple of days because of something that should be done in about hours.

We all talk about separating layers. But when it comes to designers vs developers, we really don't care about because we are trying to push an idea of programmers that are able to design just like designers, or designers able to code as programmers. That just won't happen. You may find one or two excellent professionals like that, but is not easy. Developers and designers have different way of thinking. The former has artistic creativity while the later has logical criativity. So if we, developers, are always saying "let's use the right tool for the right job", what's happening with the designer? His work is not being done in the right tool. I've seen designers with IDEs installed on their Macs because they have to run the project to see how it's looking like.

What if he could simply use Coda or Dreamweaver or TextMate as he does but then just preview the damn HTML in the browser, which is the right tool for him? What if he could simply preview the code that will actually be send to the client? What if he could... do his work with the best tools available? The best tool for his job.

I believe in and code with a Web Framework that helps both Developers and Designers to execute their tasks with the best tools they know. A developer should concern on data, on logic, on security. A designer should concern on layout, design, colors, UX. And what one does should not break the work done by the other.

Without mixing dynamic code with HTML, or even worse, replacing HTML elements with Tag Libraries (JSP, JSF and others), the designer can just open the HTML in the browser and see how is the prototype.

You know that prototype your designer has worked on for a week to get approval from your customer? You can just use that with minimal changes, and the prototype can still be statically functional and also run in the server. If you get an email asking for a change in the layout, no problem. Ask your designer to change the HTML, he will preview in the browser, get approval from the customer, and your developer won't have to change a line.

This is what Web Frameworks are missing. This is what I'd like to see implemented in any Web Framework. This is what Apache Wicket is providing.

The rest is just scaffolding, templates and code generation.

The future is of course static HTMLs, JavaScript and REST+JSON. Web frameworks are dead.
But until the future comes, let's just improve the web development process a little bit, shall we?