Thanks Jeff, that was a really interesting report. I'd like to do something like this - unfortunately, it's difficult to enforce here because many students would start the riots (just kidding) :)
As for the local economy, it's not a problem in a sense of employment opportunity - half of them eventually move to EU, Canada or USA. The problem is more with the alternative/exotic/emerging languages - they simply want something that guarantees employment locally and abroad (Java/.NET), and they are right. On Jan 14, 11:55 am, Jeff Rose <ros...@gmail.com> wrote: > Dober dan gospodine, > > A few years ago I taught two semesters of web application programming > to undergraduates using Ruby on Rails. None of them had any > experience with either programming in Ruby or developing for the web > before we started, but by most accounts it was a success. Maybe some > of what we learned can help you... > > We structured the class as if we were all working on an open source > project together. We setup a Subversion repository and a mailing > list, and asked everyone to brainstorm project ideas during the first > few weeks of the course while they were learning the basics of Ruby > through a series of short programming exercises. Eventually every > student submitted an idea or two, and they all voted to create a wiki > like system that supported multi-media in a nice way. From there on, > we operated in two week cycles. At the beginning of each cycle we > would have a class discussion about what features to work on, which > bugs to fix, how to design important parts of the system, etc. > Everyone had to choose something they wanted to work on, submit a > short description of what they would do and how they plan on doing it, > and then do it. Communication on the mailing list started slow. > People were nervous about embarrassing themselves in front of their > classmates, and everyone was just starting in Ruby. The first commits > to the source tree were also pretty small and quite often very buggy. > Every time a student came to us with questions we would ask them to > first post it to the list though, and every time someone found a bug > we asked them to post it so we can put it on the TODO list for next > cycle. > > For the first 5-6 weeks of the project we spent most of the lectures > going through code together, teaching more detailed lectures on web > app architecture, routing HTTP requests, model-view-controller, object > relational mapping, view templates, a little about javascript, etc. > Every lecture started with a clarification section though. Typically > about 10 minutes covering concepts that we could tell people were > struggling with by looking at their patches each week. > > Eventually it really took off. Traffic on the mailing list literally > doubled every couple weeks from the start to the finish of the > semester, and submissions to the source tree kept getting more > interesting and more effective. There were plenty of bumps in the > road, social problems between competing interests, and all the other > student/open-source debates that come up, but that was also part of > the reason for doing the course the way we did it. By the end of the > semester they had a working application with lots of cool > functionality to demo to the rest of the faculty, and not only did the > students seem more confident in terms of picking up a new language and > a new technology, but they were also comfortable joining mailing lists > and taking part in the greater software development community. > > My advice would be to have a lecture plan for every week, whether you > get to it or not. Students feel it when the course lacks structure, > and in turn they will lose motivation and discipline also. Try to > setup some policies in the beginning in terms of how assignments work, > when things are due, and what kind of code you expect, and then stick > with it. I guess this is kind of generic advice, but especially in a > class that feels less traditional I think it's even more important to > have this kind of stability for the students. It was definitely the > more challenging part of teaching for us, but when we succeeded it was > obvious. > > Good luck! > > -Jeff > > P.S. The great thing about the internet and the software world is > that it doesn't really matter where you are. If your students learn > the right skills and practice lots I think they have a good chance of > finding work remotely or creating sites/services that can be used by > the rest of the world. Don't let a limited local economy limit their > ambitions. > > > > > Hi, > > > This semester I'm teaching a course at MSc studies, and I decided to > > base it on Clojure. Sorry, It's not a sign that Clojure gets the > > ground in USA - I'm in South-Eastern Europe, at University of Belgrade > > (cca 90.000 students altogether, the largest university in the region, > > but underdeveloped economy comparing to EU). > > The course title is not that important, as I am free to organize it as > > I like (for the curious, it's "Tools and Methods of Software > > Engineering"). > > > In this region, Lisp is non-existent in the industry, which is usually > > based on Java, Oracle stack or Microsoft stack, plus the usual PHP in > > smaller projects and with the hobbyist crowd. > > The undergraduate courses are based on Java and in a smaller extent > > C#, so it's a usual "traditional" programming mindset. > > The faculty I'm teaching at is an exotic mixture of management / > > information systems departments, so even inf. syst. students attend > > more management-related than IS-related courses. So, not many typical > > geeks are going to be in the crowd. This course is a part of Software > > Engineering module that does not exist at undergraduate level, only > > Master/PhD. I expect 30 students total, 10 active and interested, 10 > > in the middle, and 10 that just want to pass. > > > I'm going to use Stuart's book as a referent literature, but the > > courses I teach are usually interactive and not that structured > > because I want to engage students to start coding and exploring as > > soon as possible and I am willing to go to whatever direction seems > > interesting to them and me. There is a method to the madness, > > though :) > > The goal of the course is to show them alternative/emerging languages > > for the JVM. Because the industry is strongly traditional, and there > > is little startup opportunity (keep in mind that this is not USA) I do > > not expect anything more than them to be able to be ready to adopt one > > of such languages if needed at one point of time in the future. > > > I hope that I'll also be able to do some research. The issue that is > > particularly interesting to me to explore is how alien Clojure is to > > Java programmers, what are subjective and objective causes, and how > > hard is to overcome each of the identified issues. I am pretty sure my > > students had no previous contact with Lisp dialects, some of them > > probably coded PHP, and there may even be someone who had some contact > > with Erlang/Ruby etc. I personally learned programming with Java, and > > Clojure was my first contact with Lisp. Common Lisp is still something > > that I would not use but Clojure was pretty easy to familiarize with, > > and looks to me as JavaLisp :) > > > Any suggestion, especially related to the research part, would be > > helpful :)
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
