First Scala User Group meeting in Milan
Yestarday we had the fisrt Scala User Group “beer meeting” in Milan. We were six person and talked about various argument, more or less related to Scala.
Aside various digressions, we tried to focus on finding a mini project to work on together, to improve our skill in Scala around a real target and then share impressions. It has been difficoult to define a project with such charateristic: quick to develop, without integration problems so we can focus on the language and that is quite interesting so we want to make it done and even use it.
Late in the evening, we end up with an idea: a CLI software that retrieves information about a specific topic from a web source and show results. This idea likes to the four people remained at that time :)
Follow discussion on the mailing list to see what’s next. I also set up http://planetsug.tumblr.com/ that aggregates Scala topics in sug-it members’ blogs.
New Build tools
Buildr and Gradle are two relatively new build tools for Java related technology I am going to test in the next weeks. Buildr is more mature and support a lot of environment like also Groovy and Scala. Gradle is newer but is growing faster.
Any of them is a modern tool that can offer all the features maven2 has while offering a cleanest way to implement features and some more advanced one. And they are compatible with maven2 projects so you can migrate easily.
At least, this is what they promise, I stille have to test them personally.
Feedback: real innovation
I have first seen this in blip.fm and I thought it was an in house development. Than I saw it on onother site and finalley noticed that there is a “powered by” llink.
UserVoice seems a real useful product: it can ben integrated with an existing site adding a real valuable feature: allow user to provide feedback in a real modern way. It is focused on one feature and almost complete. It is realized as great Software are meant to be: do one thing and do it good.
I will definitely give it a try.
The moment I see the new GMail buttons I get curious. Today I go and look how they are done inspecting with firebug and… no images, no input and no links. How the hell? Well, this evening news feed carousel gave me the answer.
The buttons are designed to look very similar to basic HTML input buttons. But they can handle multiple interactions with one basic design. The buttons we’re using are imageless, and they’re created entirely using HTML and CSS,
quick scala-lift project
mvn archetype:create -U \
-DarchetypeGroupId=net.liftweb \
-DarchetypeArtifactId=lift-archetype-basic \
-DarchetypeVersion=0.10 \
-DremoteRepositories=http://scala-tools.org/repo-releases \
-DgroupId=sug -DartifactId=sug-app
cd sug-app
mvn eclipse:eclipse
mvn jetty:run
pronta l'applicazione con gia' registrazione utente e login!
http://liftweb.net/index.php/HowTo_start_a_new_liftwebapp
The "A developer" is too much.
At java.dzone appeared an article that want to summarize the charateristics of the “A” developer”, a first class one. It starts with:
1) ‘A’ Developer writes her/his code with a lot of enjoyment and enthusiasm.
2) ‘A’ Developer is not a coder; ‘A’ Developer is an ENGINEER.
3) ‘A’ Developer is always asking “Why” before starting to learn a new technology. For example, “Why Spring?”, “Why JPA?”, “Why JSF?”
And go on for other eighteen points. Eighteen. I think that they are too much. More over, I disagree with some of that points:
4) ‘A’ Developer is Big Picture oriented, not details oriented.
But, devil is in the details! :)
5) ‘A’ Developer believes that Design Patterns are a MUST
Almost. A Developer in 2009 does not even need to think in terms of design pattern. The developer who think in that terms simply try to apply dumbly some pattern.
We have Object Orientation principles, or even better, we have “do not duplicate code” principle that can guide us. Patterns are… well, just pattern to find a pre cooked solutions.
6) ‘A’ Developer should be involved in all tiers.
I agree a lot with this. One problem in opur industry is the distinction between the developer (seen as a “programmer”), the designer, the architect and so on. I think that distinction is useless. Obviously different developers have different level of expertize so some take the most important architectural decisions and so on, but I think that we should get rid of that role division. The roles in eXtreme Programming, for examle, better fit the real need of a software team.
7) ‘A’ Developer is a good starter and a good finisher as well.
Yeah, I have to remember this :)
8) ‘A’ Developer has v.good communication skills.
9) ‘A’ Developer does not depend on “Hello World” examples when trying to learn and master a new technology .
Fair enough, but a new technology must have a zero-effort hello world examples, or very probably it does not worth to be tried.
10)’A’ Developer is always updating him/herself with the latest market news and reads developers articles and comments.
11)’A’ Developer is not a fantasist in terms of the latest framework or technology.
12)’A’ Developer is a very good user to his IDE. He/she knows the most important options and shortcuts the IDE has.
I agree a LOT with this. You have to be real smart when using your everyday tool. This means you are comfortable with them couse you can work at a different level of abstraction from the “language” and the “system”, the level the tool can give you
13)’A’ Developer hates the systematic route and always asks: “How I can automate this.”
Simply, a DOGMA (1)
14)’A’ Developer tends to keep things simple.
Simply, a DOGMA (2)
15)’A’ Developer is a reliable, committed, and hard worker.
Well, I do not find this to be completely true. It seems to justify the approach: the more hours you work, the better developer are you. I use to be real productive on my daily development task while focusing on them for at most 4 hours a day, while spending almost other 4 on not losing touch with actual development (mine and others of the team), reading news, taking the needed break to be more productive on the next programming session :)
16)’A’ Developer likes new challenges.
well of course… but…
17)’A’ Developer understands the business before beginning to code.
18)’A’ Developer looks for the best practice for everything he/she works on.
My observation in a comment to the original post, is that we have too much point. I will try to cut theme down in a more simple and significant list
