Dev-Day at Tikal
We are considering to shift our Java group meetings into “hands-on developer day”, and I would like to get your feedback, comments, ideas and suggestions.
The main target of this day is to expose our group members to new technologies, train and practice them in hands-on development of “Fuse” like applications, and exchange ideas with other members. We can store our applications in Tikal-Fuse repository, and the produced artifacts will also help developers to kick off new products and projects on our customers sites.
The dev-day will be led by 1-2 people that will be the "Meeting Leader". They will serve as the technical focal point - introduce the subjects , answer and help people during the day.
I think Maven can be the build tool for the system, while the chosen IDE can be used freely by the groups. Sources will be stored on version-control (we may also add them to Hudson for better CI), and the artifacts will be run on hosted environment (wither at Tikal, GAE , external hosted service, or Amazon EC2). We can also use some issue tracker to track issues and improvements.
I suggest the following agenda for the “Dev-Day”.
- Lecture by the "Meeting Leader" (1-1.5 hours).
- Application definitions and requirements - In this part, the leader will introduce the 1-2 "fuse apps", which will be developed during the day. (0.5 hours)
- Split into groups and start development (5 hours + 0.5 hour break) . The groups can be either heterogeneous (sever+client) in which the application will be developed "end to end" (2-3 developers), or homogeneous (1-2 developers), in which we will also match pairs of groups to achieve end to end application.
- Work Presentation (1 hour) - the groups will introduce their work to the while forum
An important note is that the time frame will be limited , and the implementation should be time driven - "Reduce features, but make sure you finish in the time frame."
The technologies, I think we can introduce are (of course , we can mix several) :
- Spring DM Server.
- Cloud computing with Amazon (we can also use Eucalyptus)
- Grid Computing
- Spring Batch
- BI technologies
- Google App Engine
- Scala
- Groovy Grails
- Spring 3 (take last milestone and use its new features)
- Spring Roo
- Web Beans
- Spring Web Flow
- UI frameworks - Java FX, JavaScript, GWT
As said, I would like to get your feedback. Will dev-day catch your interest ? Do you think you will come to meetings? Anything we can do better?
Is it better to create over and over the same application with different technologies, or should we develop each time different application, which is more “classic” case for the relevant technologies.
Please comment and suggest projects which can be appropriate to the time frame - anything you can think that will interest people. For example :
1.A proxy that work with REST api against Google Picasa (search/upload pictures/videos)
2.BI project on top of SVN.
Please comment if you prefer to concentrate on Java world technologies, or do you prefer to extend to more programming languages that can be run on the JVM or even extend it to other technologies (Flex, Python etc).
Which deployment environment is better for us - Tikal's hosts, Amazon EC2, Google App engine, third party hosting service?
… and actually any related issue that can help us to to make this day more successful and fun for us...
Thanks in advance,
Yanai
Comments
i think its a good idea, I think it will be more practical then the format we have now that only gives a brief introduction to some technology while a workshop day will be more beneficial.
regarding the material I think we should take a real life problem for every meeting and show the best way or some ways to solve it, even if its a language other then java.
Great , Thanks
I think it's a great idea! The current format of a short meeting doesn't allow you to experience the material, it only gives you a taste of it and until the time is right to use it, you don't remember how..
About the material,there are so much out there, I don't think we should limit ourself to a certain area, lets look at recent trends, try to forecast trends maybe, on the other hand check which technologies are most needed by customers
Thanks
From my experience developing together on such meetings - we will spent a lot of time to configuring environment (eclipse,network,svn etc). It will like Yom Gibush, that is also very good, but it will not productive work.
I prefer more lectures about different technologies.
May be better to define projects - Google Picasa / BI over SVN, and different people develop them using different technologies at home and demonstrate it on Dev Day.
Thanks. Don't you think that a good preparation of the "Meeting leader" can help?
We can prepare both build environment and runtime environment, so people will be focused on development and learning of the library/framework. In addition, we might ask from the people to read some materials before the lecture, so it will help them get into the the session and work more smoothly. One of the reason we want to apply the shift, is to provide added value to the lecture (Please note that first stage of the day will be the lecture in the same format), and might help people to practice what they learned from the lecture (see Hilla reply above)
Yanai, How you going to organise this day?
Is it will full day? and Where ? Tikal Office ?
Every one will work on his laptop? If yes, there should be enough power sockets.
I just don't understand.
My doubts are from many courses I was (Sela, Interbit). Even in the computer class with prepared environments, after lecture exercises are not productive.
hi,
Since the Dev Day was originally my proposal, I feel the itch to say a couple of words about it, although I'll just be helping with it, not managing it -
When starting to think about Dev Day, I had a "Hackathon" event in mind, not a course with labs. Hackahons are weekends events, usually 2 days in a row, during which a group of people sits together and develops a relatively small, fun project, usually one that is deployed on the web and serves some useful or cool purpose. We, on the other hand, don't have the entire weekend, but we believe we can nonetheless make this a fun event and to learn a few things while doing it.
The details aren't just yet finalized, but the majority of time will be dedicated to this project and not the frontal lecture. This way, we hope, people would get a chance to turn their theoretical knowledge into practice, and share each other's experiences at the end of the day.
The most important thing for this effort to be successful - actually, the two most crucial factors are:
a. Participants' level of activity and enthusiasm - nothing surprising, yes? - a certain level of proactivity is required to make this work.
b. Project management - assigning tasks to people, getting real-time feedback, help troubleshooting, guidance on applying XP techniques such as pair programming, iterational development, etc.
As for the man/machine issue. We were thinking of 2-3 people working on one machine. In average, we have at least 1:2 machine/people ration, so it should be okay. Pair programming seems ideal for our scenario, is much more fun, and will enable rapid development. A certain level of maturity is needed in order to work in pairs, but I think all Tikal employees, being consultants that work at 3rd party clients and maintain professional relationships on a daily basis, have at least that level.
Hope that answers at least some of your questions,
cheers,
Zvika
Peer programming is meant mainly for code review. Unless there is a machine allocated for each developer, it is not IMHO considered hands on. One can not learn how to play the piano by merely watching somebody else playing ...
I have to disagree,
When two people are focused on the same code, it doesn't matter who's doing the actual typing. It only takes slight letting go of the ego, and you get productivity and code quality boost which is more than x2... when you code on your own, you constantly make assumptions that might not be reasonable or even needed, and the fact that someone else is there with her perspective helps reducing these assumptions.
Yanai, i think if we can arrange a "hands on day" on some technologies that would be great. It doesn't mean we need to stop "team meetings" but in some cases technology is easier to grasp if you learn it with your fingers.
I am lack of experience in some Spring issues. I'd love to try Wicket too.
Also - .NET/Flex hands on is also very appealing.
.NET ... right...
Sounds like you have (far) to many free hours on your schedule... I recommend collecting insects.
collecting insects - entomology is not my primary interest. But if i'll have some extra hours in my schedule - i certainly might try.
Everything you (Zvika) wrote holds true for the case of code review and for true peer programming, not for the case of an hands on session in which you are studying something new. What does it have to do with ego ... ? Isn't every student entitled to have a dedicated computer to practice on?
how is practicing a new technology different from an existing one?
I've taught plenty of java/j2ee/web courses back in the days, and most people preferred and seemed to work better in pairs. Ok, I will exclude genious programmers, but who is that genious that she cannot benefit from an extra eye looking at the code and an extra brain discussing it? besides, collaboration has other benefits, socializing is one.
What I meant with letting go of ego is that if I, as a participant, am not willing to loosen my strict ideas of the ways things should be done, than it would lead to clashes or active+passive role playing.
Definition of: peer/pair programming:
"Writing the source code of a program in teams of two. Also called "peer programming," each person looks at the code the other member is writing or directly after it is written. The collaboration, plus the fact that each is validating the other, ensures that more thought goes into the writing of each routine. It also helps to ensure that the code is self documenting or, at least, better documented. See self-documenting code and XP."
We do peer programming on a weekly basis which makes sense since:
1-I (or the other programmer who is with me), wrote the code, reviewed and and we are ready to sit together and conduct "peer programming", e.g. receive comments, find bugs etc. etc.
2-The result as you noted is truly beneficial since the other programmer learns about teh modules I worte and next week I shall learn about his modules.
This is not the case when one comes to a class to study for instance "Scala" (the new technology as you refer to it). It has nothing to do with "peer programming" and nothing to do with in (in)-genius programmers.
I guess it boils down to personal preferences and beliefs.
Personally, I feel that working as well as learning in pairs (a.k.a. CHEVRUTA in Jewish scholars tradition) can boost almost any sort of mental work, but that's me I guess...
Do the bares in the freezing Alaskan ponds, eat a salmon sushi only by watching their mother? No , they have to use their claws and catch it!
Did Yo-Yo-Ma watch his teacher pluck the strings on his cello all his life? No, he practiced every day for hours by himself.
Has Iran built a bomb only by reading books? No, they dug plutonium with their bare hands.
We can sit BE CHEVRUTA to watch a nice movie if you wish :)
:)
sure,
and if I may add my own example,
no bear has ever learned Scala via pair(bear?) programming...
just a small note, an fyi, whatever:
The term CHEVRUTA means one person and one person only (as in pair programming, actually); and so, BE-CHEVRUTA is a misnomer.
אחרוג ממנהגי ואשיב לך, מלומדי היקר, בשפת הקודש:
לדאבון לב, ברי כי ידיעותיך את רזי השפה העברית הינן לאקוניות. אשמח לשבת עימך בחברותא, וללמדך, ואין חולק כי תצא נשכר.
"
למידה שיתופית יכולה להיערך בקבוצות קטנות מאד, (זוג הלומד בחברותא ...
"
http://wiki.ohalo.ac.il/index.php?title=%D7%A9%D7%99%D7%97%D7%94:%D7%9C%...
מילא שפת הקודש, אבל מי מבין לועזית
http://he.wikipedia.org/wiki/%D7%9C%D7%90%D7%A7%D7%95%D7%A0%D7%99%D7%94
הגם אתה, ברוטוס?
אתה וצביקה יכולים לשבת יחדיו ולהכין סושי לבאי יום הפיתוח הבא עלינו לטובה. כך כולם יחטפן קילקול קיבה ויקבלו יום חופש במתנה.
זה כפןף לכך שצביקה יחלוק עימך את הסכין סושי שלו שהרי עסקינן בצמד חמד היושב בחברותא.
שבת שלום לכולם,
שוב פעם אתה שולח אותי לויקיפדיה,אתה יודע כמה כתוב על ברוטוס שם? השתגעת?
אבל כמו שברוטוס שנוי במחלוקת,כך גם הדיון הזה שכבר מתחיל להחליק מטה.