Patching the erlang.el mode
Let's have emacs to compile in ebin directory
When you use Emacs to develop erlang code, if you follow the standard convention, an annoying thing of the emacs mode is that it compiles the erlang source in the same directory.
Usually you have a src directory where you put sources, but you expect that the compiled code (the .beam) goes in the ebin directory. So you should compile in ../ebin, usually
Usually you have a src directory where you put sources, but you expect that the compiled code (the .beam) goes in the ebin directory. So you should compile in ../ebin, usually
Using a wiki for software development?
I am not sure is the best thing.
There is a Wiki software I like a lot: JamWiki. It is an open source software project, and I would like to collaborate with it. But I feel lost because the author, that is however very active and responsive, is using the wiki to coordinate the development. He says the wiki is the best way to collaborate...
I am not sure that it is better than a traditional mailing list. The main problem I see: the sequentiality of events is lost. Also it is missing the focus on what is happening.
In the traditional way, I mean open source with a mailing list, things happens in a precise order. For example, I make a proposal, and everyone knows (or choose to ignore...). Then I have a response from the benevolent dictator, and everyone knows. Then I sent a patch, then some maintainer merge the code and so on.
With a wiki, I discuss editing some page, but HOW other people know about this? There is the RecentChanges log, but I have to diff page to see and understand what is happening. It is awkward enough to be impractical. Maybe with sort of automated diff sent to a mailing list... but why reinvent the wheel?
I vote for a traditional mailing list over the wiki collaboration for developing software.
Of course, if we are talking about writing and sharing documentation, I think instead that a wiki is the best thing ever invented...
I am not sure that it is better than a traditional mailing list. The main problem I see: the sequentiality of events is lost. Also it is missing the focus on what is happening.
In the traditional way, I mean open source with a mailing list, things happens in a precise order. For example, I make a proposal, and everyone knows (or choose to ignore...). Then I have a response from the benevolent dictator, and everyone knows. Then I sent a patch, then some maintainer merge the code and so on.
With a wiki, I discuss editing some page, but HOW other people know about this? There is the RecentChanges log, but I have to diff page to see and understand what is happening. It is awkward enough to be impractical. Maybe with sort of automated diff sent to a mailing list... but why reinvent the wheel?
I vote for a traditional mailing list over the wiki collaboration for developing software.
Of course, if we are talking about writing and sharing documentation, I think instead that a wiki is the best thing ever invented...
The most frequent 3000 english words in VIDEO
A useful tool to memorize correct english spelling
Do you need help in memorize the correct pronunciation of the most frequent english words? I realized this video for my own use:
I put it in my mobile phone and listened several times. Then I found my english pronuciation improved, so I decided to share the video.
Log4J reloadable in JBoss
The big value of having a logging service
One of the most annoying and recurrent problem in deploying off-the-shelf open source java application in JBoss is the log4j conflict. For example I incurred in the problem trying to deploy JamWiki
Because JBoss provide his own version of the Log4J libraries, if you have in your application your log4j, there is usually a conflict.
There are ways of solve this problem, the simplest one is to remove Log4j from your application and use the JBoss one.
At the first glance, this look as an ugly solution, but recently discovered a big value with it: if you use the JBoss provided log4j, the configuration is reloadable without having to restart the application server or redeploy the application,
This is a great advantage when you debug your application (I LOVE debug by logging). Instead of having all sort of debug enabled, just in case you miss some important informations, when running on JBoss you can safely turn off everything, or just enable what you consider always useful.
When you approach a buggy section, you can enable on-the-fly the debug log you need, just editing the log4j.xml file. And of course you can also easily create new appender, in order to save in a file some relevant detail of your application.
I fell in love with this idea so much that this is the main reason I will use JBoss instead of plain Tomcat (as I used to do in the past) in my future development.
Because JBoss provide his own version of the Log4J libraries, if you have in your application your log4j, there is usually a conflict.
There are ways of solve this problem, the simplest one is to remove Log4j from your application and use the JBoss one.
At the first glance, this look as an ugly solution, but recently discovered a big value with it: if you use the JBoss provided log4j, the configuration is reloadable without having to restart the application server or redeploy the application,
This is a great advantage when you debug your application (I LOVE debug by logging). Instead of having all sort of debug enabled, just in case you miss some important informations, when running on JBoss you can safely turn off everything, or just enable what you consider always useful.
When you approach a buggy section, you can enable on-the-fly the debug log you need, just editing the log4j.xml file. And of course you can also easily create new appender, in order to save in a file some relevant detail of your application.
I fell in love with this idea so much that this is the main reason I will use JBoss instead of plain Tomcat (as I used to do in the past) in my future development.
Mac Power Book, the universal machine
Why I switched to Mac after years of Windows and Linux
My machine is a MacBookPro since april. After carefully consideration, and considering my experience with It, I say why I don't think I will switch back.