Tuesday I managed to seen a bit less things from the conference since I had to work as part of my student volunteer program for most of the day. I managed to see the opening keynote and at the end of the day, have a session of traditional Coding Dojo.
The opening keynote was from an archeologist named Mark Lehner who dedicated over 30 years of his life to the history of Egypt. He had a long talk about the way the pyramids are viewed and his search for the city that existed to support the pyramids constructions. Aside from several very interesting information about archeology and the way archeologists work, his talk showed how modular the city that built the pyramids was. Amazingly, the houses of the workers were all pretty much the same several times replicated as instances of a model. He also showed that the hierarquical structure among the builders was the same as in every social organization where roles were different acording to the structure where you were, or simply polymorphic.
All this is interesting and shows the ideas we have nowadays are not even close to be new and have been used over and over. Reassuring but no big deal to me. What amazed me was that those things only happend in the city that built the pyramids and the people in it. The pyramids themselves not modular or polymorphic at all. They are carefully hand crafted to and not slightly modular. I don't know yet what to take away from this information but it sure sounds like something we should think about.
During the day I did a few volunteers task. I ended my day by attending to the Coding Dojo session. First of all, I wish people with the Javascript library called 'dojo' would rename their project to something more appropriate. According to their own website, 'dojo' is just a name that won't get them sued. Coding Dojos actually do have a reason to be called as such and I had a few people coming over thinking we were going to talk about the library which is somehow anoying. Anyway, we had a small group (4 people including me and Mariana) and we attacked the Minesweeper problem in Java. We managed to code a solution but we were not really very pleased with it at the end. Mostly because we only had two tests (although we had a 100% coverage) and we took some very big steps during the solution. This is a very common outcome for a first session of a Coding Dojo. Feeling which tests will result in a major step is something that does not have (yet?) a Shu or Ha description and is usually learned with practice and time.
That's about it for Tuesdays. I'll post a bit about the following days later on this week.
Enjoy yourselves.
Monday, October 27, 2008
Empty open spaces at OOPSLA'08
Hi again,
I spent most of Monday afternoon at the Open Space area at OOPSLA. Open spaces are a very interesting concept to get people gather around a subject. It is based on the fact that it is much more useful to have a conversation than a monologue. Therefore, traditional presentations are less useful than getting people together to chat with each other.
So what you need to have an open space?
Well, space, a big board, a few tables, a lot of chairs, flip charts and, maybe, just maybe, one projector. On the big board, write down a time schedule with several areas available (places with chairs and a table) and provide a way for people to suggest their topics.
After that, you need to warn people about a few things. There are 4 rules on open spaces and one law. The rules are:
This also allows for two specific behaviors. The first one is the butterfly one which consist of flying around the spaces just to check what is going on without participating actively or staying anywhere. Those can generate new subjects when meeting another of their species. The second one are the bumble bees. Those go around each conversation and sit for a while, engage in the discussion and then leave to another area. Those ones allow for information and different perspectives to flow across the areas. Both should be welcome and accepted in an open space environment.
This was the first year OOPSLA had an open space are. Dirk Reihle was responsible for that but, sadly, he got stuck in Germany trying to get his work visa to the US. Luckily enough, Deborah Hartmann was there to replace him. Since OOPSLA's open activities really only start on Tuesday, the area was quite empty on Monday afternoon and the Coding Dojo session I had suggested with Mariana ended up empty. We then decided to help Deborah in creating an interactive poster to present the Open Space during the poster presentations at the ice breaker reception later that day. We came up with a three areas poster: What is an Open Space? - The schedule for Tuesday, Wednesday and Thursday - What questions would you like to have answered by Friday?
The idea was to get both people aware of open spaces and people that had no idea what it was to collaborate in order to create new sessions. And indeed, during the reception, we managed to get some people to suggest topics and get interested in the topics that are posted. And that closed Monday around 9pm and we went straight to bed to sleep.
That was it for Monday. If you have ever been to an open space and would like to give a better description than mine, please do so in the comments here or post a link to your blog. If you would like to have an open space going, contact me or post a comment and I can try to help or get you in touch with other helpers.
I spent most of Monday afternoon at the Open Space area at OOPSLA. Open spaces are a very interesting concept to get people gather around a subject. It is based on the fact that it is much more useful to have a conversation than a monologue. Therefore, traditional presentations are less useful than getting people together to chat with each other.
So what you need to have an open space?
Well, space, a big board, a few tables, a lot of chairs, flip charts and, maybe, just maybe, one projector. On the big board, write down a time schedule with several areas available (places with chairs and a table) and provide a way for people to suggest their topics.
After that, you need to warn people about a few things. There are 4 rules on open spaces and one law. The rules are:
- It starts when it starts
This means that people can be late, people can just post and sit and start talking or people can start it before or after the time schedule. - Those who attend are the right persons
Whoever comes in is welcome and should be there. No matter if that person does not know much about the subject or is an expert. A lot of very interesting things can be achieved by just gathering people that know very little about a subject but are willing to spend some time thinking about it. - Whatever happens was the only thing that could have happened
If the output of the meeting is that this subject is useless to be discussed, so be it. It is still a very good thing to learn. If, on the other hand, you decide that the people there are more interested in something else and you change themes, great too! - It ends when it ends
There is no need to speed or slow people to finish on schedule. If the subject has not been fully discussed, stay. If it has, go. Nothing to worry about.
This also allows for two specific behaviors. The first one is the butterfly one which consist of flying around the spaces just to check what is going on without participating actively or staying anywhere. Those can generate new subjects when meeting another of their species. The second one are the bumble bees. Those go around each conversation and sit for a while, engage in the discussion and then leave to another area. Those ones allow for information and different perspectives to flow across the areas. Both should be welcome and accepted in an open space environment.
This was the first year OOPSLA had an open space are. Dirk Reihle was responsible for that but, sadly, he got stuck in Germany trying to get his work visa to the US. Luckily enough, Deborah Hartmann was there to replace him. Since OOPSLA's open activities really only start on Tuesday, the area was quite empty on Monday afternoon and the Coding Dojo session I had suggested with Mariana ended up empty. We then decided to help Deborah in creating an interactive poster to present the Open Space during the poster presentations at the ice breaker reception later that day. We came up with a three areas poster: What is an Open Space? - The schedule for Tuesday, Wednesday and Thursday - What questions would you like to have answered by Friday?
The idea was to get both people aware of open spaces and people that had no idea what it was to collaborate in order to create new sessions. And indeed, during the reception, we managed to get some people to suggest topics and get interested in the topics that are posted. And that closed Monday around 9pm and we went straight to bed to sleep.
That was it for Monday. If you have ever been to an open space and would like to give a better description than mine, please do so in the comments here or post a link to your blog. If you would like to have an open space going, contact me or post a comment and I can try to help or get you in touch with other helpers.
Marcadores:
coding dojo,
oopsla,
open space,
trips
Crystal Monday morning at OOPSLA 2008
Hello,
As always with OOPSLA, once it starts it is very hard to keep anything updated since we get so busy. Monday was an interesting day.
I had to pleasure to attend to Alistair Cockburn's tutorial called Crystal Clear Methodology. As I expected it was very interesting. Alistair's work is well known and I am surely not the best person to talk about it but I will try anyway. Although I already heard about the Shu-Ha-Ri levels of knowledge (that are not that far from Apprentice-Novice-Expert-Master from the Dreyfus model), it is always better the have them explained from someone that know them very well.
The idea is that the Shu level of knowledge is the one where you want to learn the basis. It basically means you want a recipe that can help you get the thing done without having to give it much thoughts. This is how you learn most of the things in life: reading, writing, riding a bike, cooking, programming and those sort of things.
Once you are comfortable at reproducing those steps, you want to have a better understanding about why the best practioners in the fields do it differently from time to time. You then pass to the Ha level. In this level, you get to collect all sorts of techniques in the field you are learning. This is when you learn the exceptions, the cases, the workarounds and stuff like that. If you take the learning to ride a bike example, this is when you can take those auxiliary wheels off and do those nice curves all by yourself. You might also learn how to straight your bike and have it running on just one wheel.
When you get to master those several techniques, you get to understand how or when to use one technique or another. At this level, you are reaching the Ri. From then on, you can pick techniques according to the context. Your answers to any question become "It depends..." and very slight changes in the environment can make you change radically the way you do things. At this level, you might even inovate with new solutions that you never really thought about, they just feel right.
If you are familiar with the Dreyfus model of knowledge, you can see very clearly that those are very closely related ideas. It is interesting to perceive how the transitions in this model are more fluid or, let's say, more oriental opposing to the transitions in the Dreyfus model being more occidental. More on those differences to come on the next posts.
The rest of Alistair's tutorial showed how XP (first edition) and Scrum are excelent Shu descriptions of Agile methods although the author are clearly at the Ri level themselves. XP (second edition) and the Crystal family, on the other hand, are, according to Alistair, better suited at the Ha level since they present a set of possible solutions according to a given environment. I personally don't think the Ri level can be learned with a book which makes me believe that we can't go much further than Crystal in the matter of describing Agile methods if Alistair is right.
There was much more content on Alistair's talk but you can learn most of it from his books.
That was it for Monday morning. More posts comming with the rest.
See you all!
As always with OOPSLA, once it starts it is very hard to keep anything updated since we get so busy. Monday was an interesting day.
I had to pleasure to attend to Alistair Cockburn's tutorial called Crystal Clear Methodology. As I expected it was very interesting. Alistair's work is well known and I am surely not the best person to talk about it but I will try anyway. Although I already heard about the Shu-Ha-Ri levels of knowledge (that are not that far from Apprentice-Novice-Expert-Master from the Dreyfus model), it is always better the have them explained from someone that know them very well.
The idea is that the Shu level of knowledge is the one where you want to learn the basis. It basically means you want a recipe that can help you get the thing done without having to give it much thoughts. This is how you learn most of the things in life: reading, writing, riding a bike, cooking, programming and those sort of things.
Once you are comfortable at reproducing those steps, you want to have a better understanding about why the best practioners in the fields do it differently from time to time. You then pass to the Ha level. In this level, you get to collect all sorts of techniques in the field you are learning. This is when you learn the exceptions, the cases, the workarounds and stuff like that. If you take the learning to ride a bike example, this is when you can take those auxiliary wheels off and do those nice curves all by yourself. You might also learn how to straight your bike and have it running on just one wheel.
When you get to master those several techniques, you get to understand how or when to use one technique or another. At this level, you are reaching the Ri. From then on, you can pick techniques according to the context. Your answers to any question become "It depends..." and very slight changes in the environment can make you change radically the way you do things. At this level, you might even inovate with new solutions that you never really thought about, they just feel right.
If you are familiar with the Dreyfus model of knowledge, you can see very clearly that those are very closely related ideas. It is interesting to perceive how the transitions in this model are more fluid or, let's say, more oriental opposing to the transitions in the Dreyfus model being more occidental. More on those differences to come on the next posts.
The rest of Alistair's tutorial showed how XP (first edition) and Scrum are excelent Shu descriptions of Agile methods although the author are clearly at the Ri level themselves. XP (second edition) and the Crystal family, on the other hand, are, according to Alistair, better suited at the Ha level since they present a set of possible solutions according to a given environment. I personally don't think the Ri level can be learned with a book which makes me believe that we can't go much further than Crystal in the matter of describing Agile methods if Alistair is right.
There was much more content on Alistair's talk but you can learn most of it from his books.
That was it for Monday morning. More posts comming with the rest.
See you all!
Sunday, October 19, 2008
First day at OOPSLA
Hello,
I am currently attending OOPSLA 2008 at Nashville, Tennessee in the USA. This is the second year that I am a student volunteer at OOPSLA. This year, there are much fewer attendees and, as far as we know, it is the financial crisys' fault.
So far, it has just started. Registration went pretty well this morning and tutorials are going OK so far. No big deal and we are yet waiting for the special talks. I would highlight Dick Gabriel's photography course that will be going on during the whole conference. Tomorrow we'll have Alistair Cockburn talking about Crystal in the morning and effective agile use cases in the afternoon. I will surely attend to the first one. I might join the second one although I might go to the Design Pattern: Next Generation's workshop by Brian Foote, Dirk Riehle and Joshua Kerievsky. I was slightly disapointed by this year's program.
Two news that were supposed to be secret but are not. The first one is that next year's OOPSLA will be held at Orlando, Floripa at some hotel inside Disney World. This means I probably won't attend it because hotels will be pretty expensive and flights will be overbooked way ahead so I don't think I'll make it. The second "secret" is that the special event will be held at the Parthenon replica in Nashville. I'll try to have Mariana's photos to post them here when we can.
That's it for now. For those of you who still want Archimedes news, please wait another week or two until I manage to get my time schedule back to regular shift. See you all.
I am currently attending OOPSLA 2008 at Nashville, Tennessee in the USA. This is the second year that I am a student volunteer at OOPSLA. This year, there are much fewer attendees and, as far as we know, it is the financial crisys' fault.
So far, it has just started. Registration went pretty well this morning and tutorials are going OK so far. No big deal and we are yet waiting for the special talks. I would highlight Dick Gabriel's photography course that will be going on during the whole conference. Tomorrow we'll have Alistair Cockburn talking about Crystal in the morning and effective agile use cases in the afternoon. I will surely attend to the first one. I might join the second one although I might go to the Design Pattern: Next Generation's workshop by Brian Foote, Dirk Riehle and Joshua Kerievsky. I was slightly disapointed by this year's program.
Two news that were supposed to be secret but are not. The first one is that next year's OOPSLA will be held at Orlando, Floripa at some hotel inside Disney World. This means I probably won't attend it because hotels will be pretty expensive and flights will be overbooked way ahead so I don't think I'll make it. The second "secret" is that the special event will be held at the Parthenon replica in Nashville. I'll try to have Mariana's photos to post them here when we can.
That's it for now. For those of you who still want Archimedes news, please wait another week or two until I manage to get my time schedule back to regular shift. See you all.
Tuesday, October 14, 2008
Coding Rumors++ or UberDojo
Hello,
I previously described the Coding Rumor game and later on presented the results we had at PyCon Brasil 2008 doing it. During the Encontro Agil, we tried having a session of what rbp (or R) called UberDojo to follow the UltraDojo idea (the name he prefered for Coding Rumor).
Just to remind you, UltraDojo (or Coding Rumor) is a Coding Dojo session where you don't need a projector. The code is written in one laptop and the pair switches with rounds just like the regular one. Everyone works on the same problem but you only get to see the code for 2 rounds (14 minutes) in which you are the co-pilot and then the pilot. If you are not on any of those roles, you can chill and chat with other people. The advantage of this is that it requires less time focusing on the problem which makes it a good practice for conferences.
The UberDojo version is just the UltraDojo game with several laptops. You should plan to have at least three people for each laptop but you can have more if you want. In this case, when the pilot leaves, he goes to the "audience" and will choose another laptop to go to on the next round.
Last Monday's session happened at Thiago's house. We were 14 people (Danilo Sato, George Malamidis, Rodrigo Bernardo Pimentel, Thiago Colucci, Fabricio Sousa Nascimento, Jacqueline Marchetti, Renato Willi, Bruno Pedroso, João Pedro Kerr Catunda - a.k.a Yoshi, Mariana Bravo, Breno Flesch, Rafael Schouery, Adolfo Rodrigues and myself). We had four laptops splitted in two round tables. Each table defined a language (Haskell and Ruby) and each side of the table defined a problem (Bank OCR and Minesweeper).
We followed 7 minutes rounds and tried to keep Haskell and Ruby "experts" available to help out people programming. At the end of each round, the co-pilots would become pilot, pilots would go away and part of the audience would join as a co-pilot on each table. We tried to keep it as random as we could in order to never repeat pairs. We had over 1 hour coding that way. It was very intense and fun. Obvisouly, we never got to finish any problem although we walked pretty well with the Haskell OCR system.
All the produced source code is available at Github on the dojo project at UberDojo-02. In retrospective people reported that is was very exciting and that it was actually a good teaching system but that they should police themselves to actually explain quickly the code to the newcomer before starting to code and be even more radical with the baby steps approach. I think this might be a very good exercise for experienced TDDers and agile teams. I believe if a team manages to actually code something slightly more complicated than Roman to Numerals, it is actually showing a lot of code cleaness. We acknowledge, however, that this sort of exercise is not especially welcoming to new people and requires quite a few experience with TDD. We agreed to have a UberDojo once a month in our meetings and keep the rest as regular dojo sessions. If you try it, please let me know what went right or wrong and your impressions.
Thanks and bye bye.
I previously described the Coding Rumor game and later on presented the results we had at PyCon Brasil 2008 doing it. During the Encontro Agil, we tried having a session of what rbp (or R) called UberDojo to follow the UltraDojo idea (the name he prefered for Coding Rumor).
Just to remind you, UltraDojo (or Coding Rumor) is a Coding Dojo session where you don't need a projector. The code is written in one laptop and the pair switches with rounds just like the regular one. Everyone works on the same problem but you only get to see the code for 2 rounds (14 minutes) in which you are the co-pilot and then the pilot. If you are not on any of those roles, you can chill and chat with other people. The advantage of this is that it requires less time focusing on the problem which makes it a good practice for conferences.
The UberDojo version is just the UltraDojo game with several laptops. You should plan to have at least three people for each laptop but you can have more if you want. In this case, when the pilot leaves, he goes to the "audience" and will choose another laptop to go to on the next round.
Last Monday's session happened at Thiago's house. We were 14 people (Danilo Sato, George Malamidis, Rodrigo Bernardo Pimentel, Thiago Colucci, Fabricio Sousa Nascimento, Jacqueline Marchetti, Renato Willi, Bruno Pedroso, João Pedro Kerr Catunda - a.k.a Yoshi, Mariana Bravo, Breno Flesch, Rafael Schouery, Adolfo Rodrigues and myself). We had four laptops splitted in two round tables. Each table defined a language (Haskell and Ruby) and each side of the table defined a problem (Bank OCR and Minesweeper).
We followed 7 minutes rounds and tried to keep Haskell and Ruby "experts" available to help out people programming. At the end of each round, the co-pilots would become pilot, pilots would go away and part of the audience would join as a co-pilot on each table. We tried to keep it as random as we could in order to never repeat pairs. We had over 1 hour coding that way. It was very intense and fun. Obvisouly, we never got to finish any problem although we walked pretty well with the Haskell OCR system.
All the produced source code is available at Github on the dojo project at UberDojo-02. In retrospective people reported that is was very exciting and that it was actually a good teaching system but that they should police themselves to actually explain quickly the code to the newcomer before starting to code and be even more radical with the baby steps approach. I think this might be a very good exercise for experienced TDDers and agile teams. I believe if a team manages to actually code something slightly more complicated than Roman to Numerals, it is actually showing a lot of code cleaness. We acknowledge, however, that this sort of exercise is not especially welcoming to new people and requires quite a few experience with TDD. We agreed to have a UberDojo once a month in our meetings and keep the rest as regular dojo sessions. If you try it, please let me know what went right or wrong and your impressions.
Thanks and bye bye.
Marcadores:
agile,
coding dojo,
uberdojo
Monday, October 13, 2008
Encontro Agil was a success!
Hello everyone,
On Saturday, we (AgilCoop) ran the first 2008 agile conference in Brazil (although TDC had quite a few agile talks, the focus was not in agile). The Encontro Agil (or Agile Meeting) happened at the IME (Instituto de Matemática e Estatística - Mathematics and Statistics Institute) of USP (University of São Paulo). The event was free (as in free beer). We had around 200 attendees, 16 speakers, 2 debates and a free lunch.
We followed several ideas from the Agile 2008 conference. We had an ongoing retrospective on a wall between the two main rooms, we had an open spaces room that was interesting but quite empty since people are not used to those ideas, we had a birds of a feather session with 5 rooms discussing several topics and a huge updatable conference schedule.
On the overall, the feedback was great. Some things people pointed out in the retrospective board: we have to have more coffee, especially in the morning and after lunch. There was a load of information to be absorbed in too little time. Maybe increase the conference size or reduce the amount of information on each talk. Hand-over material has to been better selected.
On the other hand, people loved the agility in the event. We had to find a replacement talker (that was me) because another talker (Jorge) was late and the talk ran quite nicely. We adjusted the schedule on the fly to allow Jorge to give his talk anyway. The free lunch was one of the great points and birds got a nice feedback too since interaction is nicer than just listening.
A few statistics of the event. We had almost 500 people that registered themselves to come. From those, only around 300 confirmed their participation on the event a couple days before. And we had 200 attendees which gives us something around 60% drops from the original registration. As it is frequent on computer science conferences, we had 16% female attendees. Around 80% of the public was either a manager or a developer and had between 25 and 45 years old. We also had 41% of the attendees that had no experience with agile methods and 43% that were novice to it (had less than 1 year of experience). To my information, 60% never contribute to free software projects and 25% contribute occasionally. Finally, music is the extra-curriculum activity that most people practice (44%) and/or would like to learn more (48%) followed closely on the learning wish list by dance (35%).
I guess this is it for now. We will have all the content of the advanced talks on the web and a few videos of the event published around. I will post those when they are available. All slides should be available at the AgilCoop web site in a few days as well as on the conference's web page.
Future conferences in Brazil that will have some agile content are Rails Summit Latin America 2008 organized by Locaweb and mainly Fabio Akita and Falando em Agile organized by Caelum. Both will happen in October while I am at OOPSLA 2008 so I won't be there but I expect them to be quite interesting.
And get ready for next year, our goal is to have at least one international speaker.
On Saturday, we (AgilCoop) ran the first 2008 agile conference in Brazil (although TDC had quite a few agile talks, the focus was not in agile). The Encontro Agil (or Agile Meeting) happened at the IME (Instituto de Matemática e Estatística - Mathematics and Statistics Institute) of USP (University of São Paulo). The event was free (as in free beer). We had around 200 attendees, 16 speakers, 2 debates and a free lunch.
We followed several ideas from the Agile 2008 conference. We had an ongoing retrospective on a wall between the two main rooms, we had an open spaces room that was interesting but quite empty since people are not used to those ideas, we had a birds of a feather session with 5 rooms discussing several topics and a huge updatable conference schedule.
On the overall, the feedback was great. Some things people pointed out in the retrospective board: we have to have more coffee, especially in the morning and after lunch. There was a load of information to be absorbed in too little time. Maybe increase the conference size or reduce the amount of information on each talk. Hand-over material has to been better selected.
On the other hand, people loved the agility in the event. We had to find a replacement talker (that was me) because another talker (Jorge) was late and the talk ran quite nicely. We adjusted the schedule on the fly to allow Jorge to give his talk anyway. The free lunch was one of the great points and birds got a nice feedback too since interaction is nicer than just listening.
A few statistics of the event. We had almost 500 people that registered themselves to come. From those, only around 300 confirmed their participation on the event a couple days before. And we had 200 attendees which gives us something around 60% drops from the original registration. As it is frequent on computer science conferences, we had 16% female attendees. Around 80% of the public was either a manager or a developer and had between 25 and 45 years old. We also had 41% of the attendees that had no experience with agile methods and 43% that were novice to it (had less than 1 year of experience). To my information, 60% never contribute to free software projects and 25% contribute occasionally. Finally, music is the extra-curriculum activity that most people practice (44%) and/or would like to learn more (48%) followed closely on the learning wish list by dance (35%).
I guess this is it for now. We will have all the content of the advanced talks on the web and a few videos of the event published around. I will post those when they are available. All slides should be available at the AgilCoop web site in a few days as well as on the conference's web page.
Future conferences in Brazil that will have some agile content are Rails Summit Latin America 2008 organized by Locaweb and mainly Fabio Akita and Falando em Agile organized by Caelum. Both will happen in October while I am at OOPSLA 2008 so I won't be there but I expect them to be quite interesting.
And get ready for next year, our goal is to have at least one international speaker.
Marcadores:
agilcoop,
agile,
encontro agil
Saturday, October 4, 2008
Archimedes' screenshots
Hello everyone,
I've just updated the archimedes web site to include user registration. Now, all the content is dynamical. Both the front page as well as the screenshots are dynamically added by a special user (me). I also implemented a release page that will soon become a download page.
The great advantage in all this is not really to the users but mostly to myself. It allows me to easily and quickly update stuff about Archimedes. Once the download page is up, I should probably give it a rest for some time. Work a bit more on the software itself.
I hope to improve this system to plug it to the repository (http://svn.archimedes.org.br/public/) and have releases and a few more stuff updated automatically. It would be fantastic. If I get it to work, I might even open this to more people to create their projects in another website. Archimedes' site will become a plug in forge in that case. I'm investing a lot into this quick feedback tool in order free more time to code later on. Let's hope it works.
During my development I found a small bug in attachment_fu. If you do not specify an image processor to your image model and you use ImageScience, gif thumbnails' path get messed up. I've sent the patch to Rick Olson but if you want it, it is simple. Open up attachment_fu.rb, go to line 85 and 86 and change them from:
attachment_options[:processor] = "#{processors.first}Processor"
processor_mod = Technoweenie::AttachmentFu::Processors.const_get(attachment_options[:processor])
to:
attachment_options[:processor] = processors.first
processor_mod = Technoweenie::AttachmentFu::Processors.const_get("#{attachment_options[:processor].to_s.classify}Processor")
Restart your server and this should do the trick.
Well, that's it for now.
Bye bye
I've just updated the archimedes web site to include user registration. Now, all the content is dynamical. Both the front page as well as the screenshots are dynamically added by a special user (me). I also implemented a release page that will soon become a download page.
The great advantage in all this is not really to the users but mostly to myself. It allows me to easily and quickly update stuff about Archimedes. Once the download page is up, I should probably give it a rest for some time. Work a bit more on the software itself.
I hope to improve this system to plug it to the repository (http://svn.archimedes.org.br/public/) and have releases and a few more stuff updated automatically. It would be fantastic. If I get it to work, I might even open this to more people to create their projects in another website. Archimedes' site will become a plug in forge in that case. I'm investing a lot into this quick feedback tool in order free more time to code later on. Let's hope it works.
During my development I found a small bug in attachment_fu. If you do not specify an image processor to your image model and you use ImageScience, gif thumbnails' path get messed up. I've sent the patch to Rick Olson but if you want it, it is simple. Open up attachment_fu.rb, go to line 85 and 86 and change them from:
attachment_options[:processor] = "#{processors.first}Processor"
processor_mod = Technoweenie::AttachmentFu::
to:
attachment_options[:processor] = processors.first
processor_mod = Technoweenie::AttachmentFu::
Restart your server and this should do the trick.
Well, that's it for now.
Bye bye
Marcadores:
archimedes,
attachment_fu,
rails
Subscribe to:
Posts (Atom)