Geertjan is on a roll: he just posted the first chapter of the NetBeans module development book on his blog. He always surpises me by his posts and always makes me say " I wish I had this when I was doing my stuff so that I wouldn't have spent as much time figuring things out on my own".
The first book on NetBeans that I've read is about NetBeans 3.5. Although that was really nice in getting me up to speed on NetBeans at the time, a lot of the things in it (especially on the module development side) don't really apply. It is a really nice book to help you understand the inner workings of NetBeans; however, at the same time, a lot of the inner workings have changed and it becomes pretty difficult to figure out on your own which one of the things in that book are still valid, and which ones aren't. From that perspective, the book that Geertjan has started would be invaluable in that respect.
Since this (hopefully) last semester I would try to focus a lot on my thesis project (which has to do with J2ME mobile video), I probably wouldn't have much time to spend on digging around the NetBeans APIs and trying to figure them out on my own. At the same time, if Geertjan continues to write this book, I could probably try to write a "parallel" set of examples that do the same things that he illustrates for Wicket and Click for Tapestry.
Saturday, September 09, 2006
Tuesday, August 22, 2006
Broken links, changed dates, etc...
Well, I guess I almost messed this one up :-) I had initially posted my Tapestry screenshots on Aug. 20th. However, since I had started blogging about it about a month earlier (on Aug 20th), when I posted the actual post, it posted with a July 20th date...
Geertjan mentioned that the project was about a month old and it might have updates, based on the posting date... So, in order not to give the false impression, I went back and updated the posting date to Aug. 20th.. Funny thing is, by then, the posting got picked up and sent out in the NetBeans weekly news newsletter.. and the link was broken... So, in order to fix the link for NetBeans users, I put it back to where originally was in the July entry . I will end up re-posting the same one at both places ( July entry , Aug entry ) to make sure all links are in place...
Damn, I am not used to being responsible and keeping the links to me constant.. :-) Nice and tickly feeling that someone might be interested in the things that I'm doing :-)
Geertjan mentioned that the project was about a month old and it might have updates, based on the posting date... So, in order not to give the false impression, I went back and updated the posting date to Aug. 20th.. Funny thing is, by then, the posting got picked up and sent out in the NetBeans weekly news newsletter.. and the link was broken... So, in order to fix the link for NetBeans users, I put it back to where originally was in the July entry . I will end up re-posting the same one at both places ( July entry , Aug entry ) to make sure all links are in place...
Damn, I am not used to being responsible and keeping the links to me constant.. :-) Nice and tickly feeling that someone might be interested in the things that I'm doing :-)
Sunday, August 20, 2006
Tapestry NetBeans Plugin
This is repost of my original post - since it was linked by Geertjan and NetBeans weekly news at two different URLs, here it goes...:
I've read up a bit on Tapestry and I've followed Geertjan's blog for quite a while now. I've been a NetBeans fan for quite a while now (since 3.5), and Geertjan's blog has been really eye opening in what is possible with NetBeans. So, a while back, he was really excited about Wicket, and he started working on a plugin for developing Wicket apps in NetBeans. It appears that in the last few months, with the help of Petr they've built quite a nice set up to support Wicket in NetBeans.
What that means about me is that I will try to do something similar, but with Tapestry. What I will try to do is to develop a plugin that will support Tapestry development in NetBeans. Geertjan has already done most of the work here as he has covered a lot of the topics that are required to build a nice web framework support plugin for NetBeans. At the same time, as he seems to point out in one of his latest entries, the information that is required to build such a plugin is either scattered all over the net (or the NetBeans.org site), or is in the source code for his Wicket support plugin . Now that I'm trying to organize my thoughts about this project better, I start noticing that he's also done a great job of documenting his work and his progress along the way. However, I guess giving it a second run wouldn't hurt anyone.
I will probably try to put up a post that would list the proposed features for such a plugin. However, the idea is that the plugin should make working with Tapestry easier, maybe even to the point of not having to know all the nitty-gritty details of exactly how Tapestry works. It should probably have all the nice features of the Wicket plugin, translated into the Tapestry world.
One thing that I've considered in the past is to dig into the Spindle project (which is an Eclipse Tapestry support plugin which has an Eclipse specific and an Eclipse agnostic part) and try to adapt it to work for NetBeans. Now, the thing is that part of my goals includes learning the NetBeans APIs along the way. So, while sometime down the road, looking into using the Spindle implementation and putting up a NetBeans frontend to it would make sense, it appears that for now it would make the most sense to see about implementing the basics in NetBeans only...
I will also probably post more details on the steps required to accomplish this; however, after a few hours of playing around with NetBeans, the tutorials on the site, Geertjan's tutorials, as well as the NetBeans APIs, I've put together the first few things for the plugin... Here are a couple of screenshots that just give me an enormous adrenaline rush...
First, a blank Tapestry project, set up and ready to go (I wish I knew how to do this a while back at work, as with both Tapestry and JSF/Facelets I've always kept referring to a sample project that I know it works when I've done new projects...):
Geertjan is probably going to laugh at this one as this is dirt simple to do, but damn, it is nice to be able t accomplish this.
The next one is showing how the Tapestry framework is added to the list of supported frameworks in a standard NetBeans web project. I admit right off the bat that I took all the code from the Wicket plugin and replaced all references to Wicket with references to Tapestry. I still need to remove some of the config options here that really have nothing to do with Tapestry, but this is a very nice start (I was initially having some trouble getting the framework support in - I spent a good number of hours until I found out exactly how to register the framework in the IDE).
The last one is a list of a couple of new file types added to a project. Most likely, I will have to restrict them to Tapestry projects only, but it's a nice start again. THere is more work to be done to maybe create a graphical customizer for a Tapestry page, but still.. I'm pumped.. :-)
I've read up a bit on Tapestry and I've followed Geertjan's blog for quite a while now. I've been a NetBeans fan for quite a while now (since 3.5), and Geertjan's blog has been really eye opening in what is possible with NetBeans. So, a while back, he was really excited about Wicket, and he started working on a plugin for developing Wicket apps in NetBeans. It appears that in the last few months, with the help of Petr they've built quite a nice set up to support Wicket in NetBeans.
What that means about me is that I will try to do something similar, but with Tapestry. What I will try to do is to develop a plugin that will support Tapestry development in NetBeans. Geertjan has already done most of the work here as he has covered a lot of the topics that are required to build a nice web framework support plugin for NetBeans. At the same time, as he seems to point out in one of his latest entries, the information that is required to build such a plugin is either scattered all over the net (or the NetBeans.org site), or is in the source code for his Wicket support plugin . Now that I'm trying to organize my thoughts about this project better, I start noticing that he's also done a great job of documenting his work and his progress along the way. However, I guess giving it a second run wouldn't hurt anyone.
I will probably try to put up a post that would list the proposed features for such a plugin. However, the idea is that the plugin should make working with Tapestry easier, maybe even to the point of not having to know all the nitty-gritty details of exactly how Tapestry works. It should probably have all the nice features of the Wicket plugin, translated into the Tapestry world.
One thing that I've considered in the past is to dig into the Spindle project (which is an Eclipse Tapestry support plugin which has an Eclipse specific and an Eclipse agnostic part) and try to adapt it to work for NetBeans. Now, the thing is that part of my goals includes learning the NetBeans APIs along the way. So, while sometime down the road, looking into using the Spindle implementation and putting up a NetBeans frontend to it would make sense, it appears that for now it would make the most sense to see about implementing the basics in NetBeans only...
I will also probably post more details on the steps required to accomplish this; however, after a few hours of playing around with NetBeans, the tutorials on the site, Geertjan's tutorials, as well as the NetBeans APIs, I've put together the first few things for the plugin... Here are a couple of screenshots that just give me an enormous adrenaline rush...
First, a blank Tapestry project, set up and ready to go (I wish I knew how to do this a while back at work, as with both Tapestry and JSF/Facelets I've always kept referring to a sample project that I know it works when I've done new projects...):
Geertjan is probably going to laugh at this one as this is dirt simple to do, but damn, it is nice to be able t accomplish this.
The next one is showing how the Tapestry framework is added to the list of supported frameworks in a standard NetBeans web project. I admit right off the bat that I took all the code from the Wicket plugin and replaced all references to Wicket with references to Tapestry. I still need to remove some of the config options here that really have nothing to do with Tapestry, but this is a very nice start (I was initially having some trouble getting the framework support in - I spent a good number of hours until I found out exactly how to register the framework in the IDE).
The last one is a list of a couple of new file types added to a project. Most likely, I will have to restrict them to Tapestry projects only, but it's a nice start again. THere is more work to be done to maybe create a graphical customizer for a Tapestry page, but still.. I'm pumped.. :-)
JVM scripting languages review
I've been playing around with groovy for the last couple of weeks and I have to say that I am intrigued by it. In the beginning, when I was starting to hear that there was a Groovy JSR that was aiming to create a standard Java scripting language, I was a bit skeptical : I've been using Jython for the last couple of years for the same puprose and so far it has been working out great for me. I already have a number of working application at work that are doing great. I even bought the "Jython for Java programmers" book a few years ago and it was an excellent guide in getting started. Additionally, in the last few months I've been getting back into the same book on the more advanced topics such as embedding jython in other applications (I even have a little prototype NetBeans plugin that is a live Jython interpeter, very nice in exploring the NetBeans APIs)
So, I said that Jython was generally working well for me for the same purpose. However, I did have a couple of things that bug me about it:
- Because Jython is an implementation of Python on top of a JVM, it is forced (or at least expected) to move at the same speed that python does. So, although Jython works pretty well for JVM scripting and and is generally feature complete, since it's a couple of releases behind Python proper, there is a lot of pressure to keep up with the language. Since one of the reasoning for using Jython is that you can either reuse python skills on the JVM, that really doesn't translate very well since Jython cannot use Python features implemented natively. Thus the "python skills transfer" thing doesn't really work.
- Although I really like the Python newline handling and indentation, it is kinda messed up that it's difficult to use python inside web pages or directly from the command line ('cause you have to maintain and respect the white space, which works great inside a regular script but it sucks when you try to do something like "jython 'for i in os.listdir("."):\n print i\n \n'"... which could have been so much better if there was another delimiter
- Because Jython has to implement the Python APIs, for a java developer to use Jython (e.g. because of the concise syntax or scripting features) he/she has to learn the totally new Python syntax and libraries (although Java most likely has equivalent APIs, using the Java APIs is not consice).
So, back to Groovy. I was initially a bit cynical, since Jython was really doing it for me (for the most part). I remember reading how the Groovy APIs were so unstable, and that it wasn't particularly catching on.. After all, I was a faithful Jython user.
So, one day I decided to give it a shot, and now, after reading about it, I am starting to really like it. For the most part, it appears to have all the goodness of Jython (e.g. concise map or list syntax, etc), however, without having to learn a totally new API. It enhances and improves Java and the JVM (e.g. Grails is really doing some really interesting things on top of Hibernate with GORM). It has a whole bunch of "best-of-breed" features taken from Ruby and Perl, without having to comply with a particular formal specification that isn't particularly Java related (e.g. such as the Python spec). It has Java-like syntax and delimiters and Java code could be used "as is" inside Groovy. Additionally, talking about syntax, it can be used nicely from the command like as in "groovy 'for i in [1,2,3] { print i }" - assuming that the for loop is correct.
All in all, so far Groovy has been really nice. I am really looking forward to the Groovy in Action book coming out so that I can dig more into it. The only thing that I really miss from Jython so far is the interactive console. I mean that Groovy that have a graphical groovy shell that can be used to execute Groovy statements, however, each statement is executed as a separate script and the results of the statements do not build up inside the script context (which might be easily fixable, but so far I don't know enough about it to fix it right off the bat).
So, I said that Jython was generally working well for me for the same purpose. However, I did have a couple of things that bug me about it:
- Because Jython is an implementation of Python on top of a JVM, it is forced (or at least expected) to move at the same speed that python does. So, although Jython works pretty well for JVM scripting and and is generally feature complete, since it's a couple of releases behind Python proper, there is a lot of pressure to keep up with the language. Since one of the reasoning for using Jython is that you can either reuse python skills on the JVM, that really doesn't translate very well since Jython cannot use Python features implemented natively. Thus the "python skills transfer" thing doesn't really work.
- Although I really like the Python newline handling and indentation, it is kinda messed up that it's difficult to use python inside web pages or directly from the command line ('cause you have to maintain and respect the white space, which works great inside a regular script but it sucks when you try to do something like "jython 'for i in os.listdir("."):\n print i\n \n'"... which could have been so much better if there was another delimiter
- Because Jython has to implement the Python APIs, for a java developer to use Jython (e.g. because of the concise syntax or scripting features) he/she has to learn the totally new Python syntax and libraries (although Java most likely has equivalent APIs, using the Java APIs is not consice).
So, back to Groovy. I was initially a bit cynical, since Jython was really doing it for me (for the most part). I remember reading how the Groovy APIs were so unstable, and that it wasn't particularly catching on.. After all, I was a faithful Jython user.
So, one day I decided to give it a shot, and now, after reading about it, I am starting to really like it. For the most part, it appears to have all the goodness of Jython (e.g. concise map or list syntax, etc), however, without having to learn a totally new API. It enhances and improves Java and the JVM (e.g. Grails is really doing some really interesting things on top of Hibernate with GORM). It has a whole bunch of "best-of-breed" features taken from Ruby and Perl, without having to comply with a particular formal specification that isn't particularly Java related (e.g. such as the Python spec). It has Java-like syntax and delimiters and Java code could be used "as is" inside Groovy. Additionally, talking about syntax, it can be used nicely from the command like as in "groovy 'for i in [1,2,3] { print i }" - assuming that the for loop is correct.
All in all, so far Groovy has been really nice. I am really looking forward to the Groovy in Action book coming out so that I can dig more into it. The only thing that I really miss from Jython so far is the interactive console. I mean that Groovy that have a graphical groovy shell that can be used to execute Groovy statements, however, each statement is executed as a separate script and the results of the statements do not build up inside the script context (which might be easily fixable, but so far I don't know enough about it to fix it right off the bat).
Wednesday, July 26, 2006
Tapestry Overview
When I was primarily doing struts and jsp development, I remember reading all these stellar Tapestry reviews and feedback, and was really planning to look into it a little further. In a few instances, I did look into the regular examples that were out there; however, at the time, I was not particularly impressed with it (that was before I looked at JSF). I mean that the syntax seemed to be pretty straightforward; however, there were all of these page and component definition descriptors that seemed to make things so much more verbose ( in a retrospect, I have to admit that at the time I was definitely not getting the idea of what a component oriented framework was all about).
So, maybe a year ago, I was a bit bored with what I'd been learning at the time ( I was kinda stuck in a rut and didn't seem to be learning much beyond the standard Struts/JSP stuff). So, I decided to learn about JSF, since it was a Java standard that seems to be pickup up speed pretty nicely. So, I sat down , read a couple of books on JSF and implemented a couple of projects with it at work and at school. It was definitely an improvement over Struts and a good learning experience. However, along the way I got to learn a couple of the not-so-savory sides of it as well. One of my biggest compaints is that it really smelled of a framework that was designed by a committed : the really simple stuff worked really nicely, it was easy to pick up and learn about; however, as soon as you started doing something not trivial (and I do mean it, not simple, but definitely not difficult stuff - e.g. selecting a row from a data table), you were immediately going up the creek... Although the framework was supposed to abstract you from the http implementation, I found myself having to deal with sessions, http requests and params, almost the same as struts... Somewhere along the way, I encountered Facelets, which was definitely an improvement over the standard JSF implementation and it was then when I realized how nice it was to have plain html implementation of the view using an extra html property for the tag to indicate framework components.
So, about a month ago, after listening to a JavaPosse interview of Howard Lewis Ship I finally decided to really give Tapestry a go. And so far, my impression is "WOW, what a refreshing and nice way to develop web apps". Although, there are a couple of things to learn from the get-go about how to start writing a Tapestry web app, after the initial slight learning curve, writing an app is really, really nice and easy. Especially now that with Tapestry 4.0 the xml descriptors can be by Tapestry annotations inside the actual page or component class makes it a less verbose.. Overall, the impression is that Tapestry came out of a practical need and evolved fulfilling all of these practical needs to make web app development more predictable and productive. Additionally, unlike JSF, Tapestry is not trying to do too many things in addition to simplifying web app development (e.g. JSF is trying to be able to have different view implementation by switching view handlers to do html, wml, and telnet). Thus, Tapestry is not unnecessarily complicated by 'possible' problems that one might have to solve when implementing web apps.
In summary, I will probably try to see what else Tapestry has to offer. So far, I really haven't have had to deal with any of the standard http/web protocols and it has been so wonderfully handled by the framework. The other day, just in a few hours, I was able to reimplement a struts app with Tapestry in a few hours. Additionally, what would have been really messy to implement before was really easy now and I found myself implementing new features that I had been thinking about in a very long time but never went ahead with it because of the mess I'd have to deal with had I had to do it in Struts. The only problem that I have encountered so far was that when I was deploying a tapestry app in JBoss 4.0.4RC1, it was giving me some errors due to the hivemind libraries being loaded multiple times (not a problem in Tomcat, as JBoss has a funny way of handling classloading). Finally, the 4.1 Tapestry release, promises a whole bunch of AJAX features that only vendor specific JSF implementation like Oracle ADF seem to offer ) and I'm really looking forward to seeing what it will bring to the table.
So, maybe a year ago, I was a bit bored with what I'd been learning at the time ( I was kinda stuck in a rut and didn't seem to be learning much beyond the standard Struts/JSP stuff). So, I decided to learn about JSF, since it was a Java standard that seems to be pickup up speed pretty nicely. So, I sat down , read a couple of books on JSF and implemented a couple of projects with it at work and at school. It was definitely an improvement over Struts and a good learning experience. However, along the way I got to learn a couple of the not-so-savory sides of it as well. One of my biggest compaints is that it really smelled of a framework that was designed by a committed : the really simple stuff worked really nicely, it was easy to pick up and learn about; however, as soon as you started doing something not trivial (and I do mean it, not simple, but definitely not difficult stuff - e.g. selecting a row from a data table), you were immediately going up the creek... Although the framework was supposed to abstract you from the http implementation, I found myself having to deal with sessions, http requests and params, almost the same as struts... Somewhere along the way, I encountered Facelets, which was definitely an improvement over the standard JSF implementation and it was then when I realized how nice it was to have plain html implementation of the view using an extra html property for the tag to indicate framework components.
So, about a month ago, after listening to a JavaPosse interview of Howard Lewis Ship I finally decided to really give Tapestry a go. And so far, my impression is "WOW, what a refreshing and nice way to develop web apps". Although, there are a couple of things to learn from the get-go about how to start writing a Tapestry web app, after the initial slight learning curve, writing an app is really, really nice and easy. Especially now that with Tapestry 4.0 the xml descriptors can be by Tapestry annotations inside the actual page or component class makes it a less verbose.. Overall, the impression is that Tapestry came out of a practical need and evolved fulfilling all of these practical needs to make web app development more predictable and productive. Additionally, unlike JSF, Tapestry is not trying to do too many things in addition to simplifying web app development (e.g. JSF is trying to be able to have different view implementation by switching view handlers to do html, wml, and telnet). Thus, Tapestry is not unnecessarily complicated by 'possible' problems that one might have to solve when implementing web apps.
In summary, I will probably try to see what else Tapestry has to offer. So far, I really haven't have had to deal with any of the standard http/web protocols and it has been so wonderfully handled by the framework. The other day, just in a few hours, I was able to reimplement a struts app with Tapestry in a few hours. Additionally, what would have been really messy to implement before was really easy now and I found myself implementing new features that I had been thinking about in a very long time but never went ahead with it because of the mess I'd have to deal with had I had to do it in Struts. The only problem that I have encountered so far was that when I was deploying a tapestry app in JBoss 4.0.4RC1, it was giving me some errors due to the hivemind libraries being loaded multiple times (not a problem in Tomcat, as JBoss has a funny way of handling classloading). Finally, the 4.1 Tapestry release, promises a whole bunch of AJAX features that only vendor specific JSF implementation like Oracle ADF seem to offer ) and I'm really looking forward to seeing what it will bring to the table.
jFreeSafe updates
I had been thinking for a while now to sit down and make some updates to jFreeSafe, and today I finally did it. The changes in themselves are nothing particularly exciting or difficult, but they were just 'nice-to-have'-s that I wish I had when I first installed the application.
My initial take was to modify the existing PasswordEntry and make the password field there to be a TextField.ANY and make it a bit longer, so that I can store more unstructured information. Actually, I used it to store CC stuff in it. Now, with the new entries, here is how it plays out:
1. CreditCardEntry : has detail fields for a bunch of common properties for a credit card (e.g. CC#, exp date, customer service number, etc).
2. NoteEntry: basically, a very generic note that has a name and allows for a long, unstructured note (actually, each entry has a long last field to allow any unforeseen types of data to be stored in it)
Below are the screenshots:
My initial take was to modify the existing PasswordEntry and make the password field there to be a TextField.ANY and make it a bit longer, so that I can store more unstructured information. Actually, I used it to store CC stuff in it. Now, with the new entries, here is how it plays out:
1. CreditCardEntry : has detail fields for a bunch of common properties for a credit card (e.g. CC#, exp date, customer service number, etc).
2. NoteEntry: basically, a very generic note that has a name and allows for a long, unstructured note (actually, each entry has a long last field to allow any unforeseen types of data to be stored in it)
Below are the screenshots:
Friday, July 21, 2006
Tapestry NetBeans plugin
I've read up a bit on Tapestry and I've followed Geertjan's blog for quite a while now. I've been a NetBeans fan for quite a while now (since 3.5), and Geertjan's blog has been really eye opening in what is possible with NetBeans. So, a while back, he was really excited about Wicket, and he started working on a plugin for developing Wicket apps in NetBeans. It appears that in the last few months, with the help of Petr they've built quite a nice set up to support Wicket in NetBeans.
What that means about me is that I will try to do something similar, but with Tapestry. What I will try to do is to develop a plugin that will support Tapestry development in NetBeans. Geertjan has already done most of the work here as he has covered a lot of the topics that are required to build a nice web framework support plugin for NetBeans. At the same time, as he seems to point out in one of his latest entries, the information that is required to build such a plugin is either scattered all over the net (or the NetBeans.org site), or is in the source code for his Wicket support plugin . Now that I'm trying to organize my thoughts about this project better, I start noticing that he's also done a great job of documenting his work and his progress along the way. However, I guess giving it a second run wouldn't hurt anyone.
I will probably try to put up a post that would list the proposed features for such a plugin. However, the idea is that the plugin should make working with Tapestry easier, maybe even to the point of not having to know all the nitty-gritty details of exactly how Tapestry works. It should probably have all the nice features of the Wicket plugin, translated into the Tapestry world.
One thing that I've considered in the past is to dig into the Spindle project (which is an Eclipse Tapestry support plugin which has an Eclipse specific and an Eclipse agnostic part) and try to adapt it to work for NetBeans. Now, the thing is that part of my goals includes learning the NetBeans APIs along the way. So, while sometime down the road, looking into using the Spindle implementation and putting up a NetBeans frontend to it would make sense, it appears that for now it would make the most sense to see about implementing the basics in NetBeans only...
I will also probably post more details on the steps required to accomplish this; however, after a few hours of playing around with NetBeans, the tutorials on the site, Geertjan's tutorials, as well as the NetBeans APIs, I've put together the first few things for the plugin... Here are a couple of screenshots that just give me an enormous adrenaline rush...
First, a blank Tapestry project, set up and ready to go (I wish I knew how to do this a while back at work, as with both Tapestry and JSF/Facelets I've always kept referring to a sample project that I know it works when I've done new projects...):
Geertjan is probably going to laugh at this one as this is dirt simple to do, but damn, it is nice to be able t accomplish this.
The next one is showing how the Tapestry framework is added to the list of supported frameworks in a standard NetBeans web project. I admit right off the bat that I took all the code from the Wicket plugin and replaced all references to Wicket with references to Tapestry. I still need to remove some of the config options here that really have nothing to do with Tapestry, but this is a very nice start (I was initially having some trouble getting the framework support in - I spent a good number of hours until I found out exactly how to register the framework in the IDE).
The last one is a list of a couple of new file types added to a project. Most likely, I will have to restrict them to Tapestry projects only, but it's a nice start again. THere is more work to be done to maybe create a graphical customizer for a Tapestry page, but still.. I'm pumped.. :-)
What that means about me is that I will try to do something similar, but with Tapestry. What I will try to do is to develop a plugin that will support Tapestry development in NetBeans. Geertjan has already done most of the work here as he has covered a lot of the topics that are required to build a nice web framework support plugin for NetBeans. At the same time, as he seems to point out in one of his latest entries, the information that is required to build such a plugin is either scattered all over the net (or the NetBeans.org site), or is in the source code for his Wicket support plugin . Now that I'm trying to organize my thoughts about this project better, I start noticing that he's also done a great job of documenting his work and his progress along the way. However, I guess giving it a second run wouldn't hurt anyone.
I will probably try to put up a post that would list the proposed features for such a plugin. However, the idea is that the plugin should make working with Tapestry easier, maybe even to the point of not having to know all the nitty-gritty details of exactly how Tapestry works. It should probably have all the nice features of the Wicket plugin, translated into the Tapestry world.
One thing that I've considered in the past is to dig into the Spindle project (which is an Eclipse Tapestry support plugin which has an Eclipse specific and an Eclipse agnostic part) and try to adapt it to work for NetBeans. Now, the thing is that part of my goals includes learning the NetBeans APIs along the way. So, while sometime down the road, looking into using the Spindle implementation and putting up a NetBeans frontend to it would make sense, it appears that for now it would make the most sense to see about implementing the basics in NetBeans only...
I will also probably post more details on the steps required to accomplish this; however, after a few hours of playing around with NetBeans, the tutorials on the site, Geertjan's tutorials, as well as the NetBeans APIs, I've put together the first few things for the plugin... Here are a couple of screenshots that just give me an enormous adrenaline rush...
First, a blank Tapestry project, set up and ready to go (I wish I knew how to do this a while back at work, as with both Tapestry and JSF/Facelets I've always kept referring to a sample project that I know it works when I've done new projects...):
Geertjan is probably going to laugh at this one as this is dirt simple to do, but damn, it is nice to be able t accomplish this.
The next one is showing how the Tapestry framework is added to the list of supported frameworks in a standard NetBeans web project. I admit right off the bat that I took all the code from the Wicket plugin and replaced all references to Wicket with references to Tapestry. I still need to remove some of the config options here that really have nothing to do with Tapestry, but this is a very nice start (I was initially having some trouble getting the framework support in - I spent a good number of hours until I found out exactly how to register the framework in the IDE).
The last one is a list of a couple of new file types added to a project. Most likely, I will have to restrict them to Tapestry projects only, but it's a nice start again. THere is more work to be done to maybe create a graphical customizer for a Tapestry page, but still.. I'm pumped.. :-)
Wednesday, July 12, 2006
JFreeSafe mystery continued...
Alright, this is a conspiracy. Up until yesterday I was having so much trouble getting JFreeSafe to work properly. For starters, I checked out the sources from cvs (assuming it was the latest version). Now, (unwisely), my initial take was to create a NetBeans J2ME project out of the existing source so that I could reuse all the goodies that my favorite IDE offers. That didn't work...class not found errors in the preverification step
Next step, was.. OK, it must be something with NetBeans, let's try to do the ant build that came with the source. I changed a couple of things in the build.properties (after checking with Laszlo, the lead of the project, it turned out that I was supposed to create a build.local.properties file which seems to be the convention) and attempted a build... and I was in trouble. First, I was getting some obfuscation errors telling me that some classes were missing.. So, I started digging in, trying to find out what's going on.. I removed the test package from cldc-crypto.jar (actually, org.bouncycastle.crypto.test), the class not found error disappeared. I actually had a good jar; however, when I attempted to install it on the phone I was getting a funky "invalid jar" error...
This is where the real hell started.. First, I thought.. it might be something in how jdk 1.5 created the jar (since the original jfreesafe distribution was build on Linux with Blackdown java 1.4.2, and I was trying Sun Java 1.5.0_3). I downloaded the latest update (1.5.0_6), same deal... I tried creating the jar with 1.4.2 sun jdk.. same deal.. I was starting to get desperate as it was getting to be almost 2 am in the morning, I had to get up at 6:30... and I still had nothing working... Oh, well, some things NEVER work on the first day you try to get them to work, no matter how hard you try...
So, the next day, I'm at it again. This time around, I tried the build on a windows box at work.. I was getting a preverification error as before.. and I didn't have much time to play around with it. So, at home, I try a different angle. I poked around the manifest and the jad files to verify that everything is kosher there. I did notice that for some reason the build was creating duplicated Manifest files inside the jar. However, deleting and attempting the reinstall didn't do much. Finally, I did notice a note on the project home page that some people were having a problem with installing 0.2.6.1 and the suggestion was to try 0.2.7.
So, I take 0.2.7 with the same expectation. However, with the first try (after modifying the appropriate properties to point to my wtk 1.0.4 install) it build the first time and successfully install... Voila!!! I was in business again, made the quick modification to the java class that was displaying the passwords, rebuilt, put it on a server, connected to my wlan (btw, my Nokia E61 ROCKS!!!), downloaded and installed the jar, everything works perfectly...
So today, encouraged by yesterday's success, I try to create an NetBeans project based on the existing 0.2.7 sources. Now, even without making it point to the wtk 1.0.4 install (using the default wtk 2.0 setup in NB), it built and I was able to successfully install on the phone... Hm... So, I try it again, this time with the same project that I was having problems previously, the 0.2.6.1 sources.. I used the same NB project from a couple of days ago: build, run, deploy, install on the phone... and IT WORKED !!! Now this is strange, the stuff that didn't work the other day works now...
So, now, I'm completely stumped as to what was exactly causing the problem before. The important thing is that I have the program running, I have a good NetBeans J2ME project that builds and installs successfully, which is an excellent prerequisite to getting some work done on this project.
For starters, I would want to add a few different types of data to be added. Currently, it only has a OTP type - not sure what that means, and a password type - for system/username/password. Since I sometimes put some credit card info in there, that probably one of the types to add - e.g. cc#, exp date, stuff like that in separate fields. The other type is just a "free" note type - something without any additional fields defined. Today, I was also thinking about adding some categories to the entries - e.g. I have quite a number of entries in the app and the list becomes quite long, so a "categorized" mode of display would probably be helpful as well.
Laszlo had mentioned in the forums that he is adding the ability to preserve the data across upgrades and installs, which would definitely a must ( I don't think I want to spend a few hours keying stuff on my phone every time something is upgraded). Additionally, along the same lines, it would probably be useful to have some way of entering the data to be put on the phone in a regular app (or just a csv file or something) and be able to "import" the data into the phone. Finally, Laszlo already has a "server" part of the project (I haven't had a chance to look at the details), and it looks like this will be covering the richer interface/synchronization uses that I mention.
Anyways, I'm looking forward to getting some stuff done with this app. It hasn't had releases in a while. I understand how things are sometimes - when it's just you working on a project, sometimes it's difficult to get motivated and excited, and to put out a release.
Now, just before I posted this, I just found out that Laszlo has a blog on JRoller: check it out - http://www.jroller.com/page/atleta
Next step, was.. OK, it must be something with NetBeans, let's try to do the ant build that came with the source. I changed a couple of things in the build.properties (after checking with Laszlo, the lead of the project, it turned out that I was supposed to create a build.local.properties file which seems to be the convention) and attempted a build... and I was in trouble. First, I was getting some obfuscation errors telling me that some classes were missing.. So, I started digging in, trying to find out what's going on.. I removed the test package from cldc-crypto.jar (actually, org.bouncycastle.crypto.test), the class not found error disappeared. I actually had a good jar; however, when I attempted to install it on the phone I was getting a funky "invalid jar" error...
This is where the real hell started.. First, I thought.. it might be something in how jdk 1.5 created the jar (since the original jfreesafe distribution was build on Linux with Blackdown java 1.4.2, and I was trying Sun Java 1.5.0_3). I downloaded the latest update (1.5.0_6), same deal... I tried creating the jar with 1.4.2 sun jdk.. same deal.. I was starting to get desperate as it was getting to be almost 2 am in the morning, I had to get up at 6:30... and I still had nothing working... Oh, well, some things NEVER work on the first day you try to get them to work, no matter how hard you try...
So, the next day, I'm at it again. This time around, I tried the build on a windows box at work.. I was getting a preverification error as before.. and I didn't have much time to play around with it. So, at home, I try a different angle. I poked around the manifest and the jad files to verify that everything is kosher there. I did notice that for some reason the build was creating duplicated Manifest files inside the jar. However, deleting and attempting the reinstall didn't do much. Finally, I did notice a note on the project home page that some people were having a problem with installing 0.2.6.1 and the suggestion was to try 0.2.7.
So, I take 0.2.7 with the same expectation. However, with the first try (after modifying the appropriate properties to point to my wtk 1.0.4 install) it build the first time and successfully install... Voila!!! I was in business again, made the quick modification to the java class that was displaying the passwords, rebuilt, put it on a server, connected to my wlan (btw, my Nokia E61 ROCKS!!!), downloaded and installed the jar, everything works perfectly...
So today, encouraged by yesterday's success, I try to create an NetBeans project based on the existing 0.2.7 sources. Now, even without making it point to the wtk 1.0.4 install (using the default wtk 2.0 setup in NB), it built and I was able to successfully install on the phone... Hm... So, I try it again, this time with the same project that I was having problems previously, the 0.2.6.1 sources.. I used the same NB project from a couple of days ago: build, run, deploy, install on the phone... and IT WORKED !!! Now this is strange, the stuff that didn't work the other day works now...
So, now, I'm completely stumped as to what was exactly causing the problem before. The important thing is that I have the program running, I have a good NetBeans J2ME project that builds and installs successfully, which is an excellent prerequisite to getting some work done on this project.
For starters, I would want to add a few different types of data to be added. Currently, it only has a OTP type - not sure what that means, and a password type - for system/username/password. Since I sometimes put some credit card info in there, that probably one of the types to add - e.g. cc#, exp date, stuff like that in separate fields. The other type is just a "free" note type - something without any additional fields defined. Today, I was also thinking about adding some categories to the entries - e.g. I have quite a number of entries in the app and the list becomes quite long, so a "categorized" mode of display would probably be helpful as well.
Laszlo had mentioned in the forums that he is adding the ability to preserve the data across upgrades and installs, which would definitely a must ( I don't think I want to spend a few hours keying stuff on my phone every time something is upgraded). Additionally, along the same lines, it would probably be useful to have some way of entering the data to be put on the phone in a regular app (or just a csv file or something) and be able to "import" the data into the phone. Finally, Laszlo already has a "server" part of the project (I haven't had a chance to look at the details), and it looks like this will be covering the richer interface/synchronization uses that I mention.
Anyways, I'm looking forward to getting some stuff done with this app. It hasn't had releases in a while. I understand how things are sometimes - when it's just you working on a project, sometimes it's difficult to get motivated and excited, and to put out a release.
Now, just before I posted this, I just found out that Laszlo has a blog on JRoller: check it out - http://www.jroller.com/page/atleta
Tuesday, July 11, 2006
JavaPassion Web Services Programming Course
I will be enrolling and will try to follow this course: Web Services Programming . I am just totally amazed that such a resource is available for free - and, really, for me, that is the best way of learning. I've determined for myself that classroom learning is very inefficient for me : e.g. if the students are not carefully pre-selected to have skills/knowledge on the same level (which usually is not the case), the instructor just ends up spending 90% of the classes teaching to the lowest common denominator.. and in the end, I just end up being bored to death in the actual classes. So, I started looking around if there is a web services class somewhere online (e.g. there are supposed to be these online universities that offer all kinds a classes).. but guess what, nothing is available. There are a number of J2EE/Web services training courses, but you have to go to their training facility (big $$$) or they have to come to your company (bigger $$$). So, it doesn't work for me.. So, I couldn't find an online course that would offer the depth that I need... it's funny, cause I'm willing to pay (actually, through the company) a decent amount of money to get a decent course..
So, this is the best. I really probably should suggest to the instructor in the course.. I don't see why Sun shouldn't make a couple of bucks off of this... Maybe have some kind of "premium" subscribers that might get extra attention... Something like that...
So, this is the best. I really probably should suggest to the instructor in the course.. I don't see why Sun shouldn't make a couple of bucks off of this... Maybe have some kind of "premium" subscribers that might get extra attention... Something like that...
Free Safe
Free Safe is an awesome j2me program that does password encryption and management on a mobile phone. Now, I had something similar on my Palm Zire; however, now that I switched to my Nokia E61, I really miss having access to all of my passwords (e.g. the other day, I was in the bank and I was trying to remember my account number..). This app provides a decent level of functionality and with a couple of enhancements will be doing exactly what I need it to do... Swweeet....
Saturday, May 13, 2006
When will Shale release ?
It's just interesting... Shale is a pretty high profile apache project and it's probably more than a year old... Looking at the shale project site, the majority of the packages and pieces of shale are still not co sidered production quality with most of the api-s not considered stable. Now, looking st what shale has to offer, and considering my experience (and a partial disappointment) with jsf, i do believe that shale will be açcepted very well, because just like struts proper it will offer a bunch of useful abstractions and utilities on top of the standard that would make it useful and popular. So, here is the paradox: there are smart and experienced people who are working on the project, probably all of them see the usefullness of what shale could be.... And ýet, for such a long time, the project has not released a stable version. On one hand I understand that having ¨struts¨ in the of the project does bring a lot of responsibility and baggage and there might be a desire to get everything to be perfect or at least excellent when 1.0 is released. On the other hand, i understand that it is an open source project and it largely depends on volunteer contributions of time and effort ( and thus, instead of blogging i probably should be reading and writing code for shale). On the other hand, it seems to me that is doesn't have to be perfect for 1.0 - it just has to be goood enough in order to be useful to a lot of people and then with usage it will start to get exponentially better....
so, my question still is : why isn't there a struts shale 1.0 yet??
so, my question still is : why isn't there a struts shale 1.0 yet??
Kudos to Jacob Hookom
A number of years ago while I was still in college.. one of my cool professors was raving about some guy who managed to connect to his cell phone from his home machine in some very sneaky and cool way.. So, my professor's comment was something like "Well, some people might say, who the hell cares about somebody connecting to a cell phone... But damn, it makes me sleep well at night when I know this kind of people are out there.. "...
So, the connection to JHook... He's the lead of the Facelets project.. and he is involved with the JSF spec committee.. He's coming up with these great ideas about web applications, components, JSF, Ajax + JSF... stuff like that.. Reading his blog is just a pleasure.. and it constantly makes me think "Thank god people like him are out there..."...
So, the connection to JHook... He's the lead of the Facelets project.. and he is involved with the JSF spec committee.. He's coming up with these great ideas about web applications, components, JSF, Ajax + JSF... stuff like that.. Reading his blog is just a pleasure.. and it constantly makes me think "Thank god people like him are out there..."...
Wicket review
A couple of weeks ago i spent a couple of hours reading up on wicket. I have to say i was quite intrigued by some posts that one of my favorite bloggers had posted ( geertjan ). He was quite ecstatic about how easy it is quite easy to develop in wiçket. Alright, i thought, let me see what it is all about.
So, i sat down and went through what i thought was almost all documentation that i could get my hands on during those few hours. I do agree that it manages to take away a lot of the complexity that is inherent to web app development - e.g. No need to deal with http requests and responses, no sessions, nothing of the sort. The development model is very similar to a swing ui development model - you just work with objects, add listeners, process events...pretty sweet feeling. All in all for a fairly small learning curve ( especially if one is already familiar with swing development), you get a fairly straightforward way to develop a web app. It turned out that the way that is possible by keeping everything in the session. Now, my first reaction ( well indoctrinated in good j2ee dev practices :-) ) was to pull back and think that something is not quite right... However, after´some further consideration... Hey, why not??? After all it is a stateful web dev framework, the state has to be preserved somwhere... Sure it's new and might have not been tested for scalability over thousands of users.. but then, for 90-some percent of the apps out there, there are a few users here and there, and really it doesn't require scalability up to thousands of users...
The templating capabilities seemed to be pretty cool as well, as you could nest and compose templates from other components up to an arbitrary depth. The templating sysstem seemed to be pretty straightforward as well, kinda similar to the facelets or the tapestry templating. So, that was nice too...
So, all in all I liked what I saw. On the other hand, I do have a strong preference for using whatever is "standard" in the particular space (or at least 2nd most popular). In light of that, although Wicket seemed to be offering a couple of interesting design options, it's far from being popular or have a large user community. Now, one of the reasons that I was actually looking at Wicket was because of the problems that I had previously with using JSF (e.g. had some problems with event handling on request-scoped components or with components inside a dataTable - both of which turned out to be well known problems with the reference implementation). In light of that, if one put everything in session scope in a JSF project,then that would solve all of the difficulties that I was having with JSF as well. Additionally, there is pretty decent support for developing with JSF (e.g. IDEs, books, etc), which wasn't really there for Wicket. Finally, it seems to me that although when you work with Wicket, often times you might not have to even touch any html, it seems to me that when I do web development, sooner or later I would have to deal with html.
Luckily, at my job, I pretty much have choice of what framework or approach to use in developing the next application. Thus, I really don't have to learn any framework or approach that I don't think would be useful in the future or wouldn't be a good investment of time from all points of view. So, from the easiness point of view, Wicket does have a lot to offer. However, at this point, at least for me, from a "future investment" point of view, I think that investing more time into JSF would be more valuable.
So, i sat down and went through what i thought was almost all documentation that i could get my hands on during those few hours. I do agree that it manages to take away a lot of the complexity that is inherent to web app development - e.g. No need to deal with http requests and responses, no sessions, nothing of the sort. The development model is very similar to a swing ui development model - you just work with objects, add listeners, process events...pretty sweet feeling. All in all for a fairly small learning curve ( especially if one is already familiar with swing development), you get a fairly straightforward way to develop a web app. It turned out that the way that is possible by keeping everything in the session. Now, my first reaction ( well indoctrinated in good j2ee dev practices :-) ) was to pull back and think that something is not quite right... However, after´some further consideration... Hey, why not??? After all it is a stateful web dev framework, the state has to be preserved somwhere... Sure it's new and might have not been tested for scalability over thousands of users.. but then, for 90-some percent of the apps out there, there are a few users here and there, and really it doesn't require scalability up to thousands of users...
The templating capabilities seemed to be pretty cool as well, as you could nest and compose templates from other components up to an arbitrary depth. The templating sysstem seemed to be pretty straightforward as well, kinda similar to the facelets or the tapestry templating. So, that was nice too...
So, all in all I liked what I saw. On the other hand, I do have a strong preference for using whatever is "standard" in the particular space (or at least 2nd most popular). In light of that, although Wicket seemed to be offering a couple of interesting design options, it's far from being popular or have a large user community. Now, one of the reasons that I was actually looking at Wicket was because of the problems that I had previously with using JSF (e.g. had some problems with event handling on request-scoped components or with components inside a dataTable - both of which turned out to be well known problems with the reference implementation). In light of that, if one put everything in session scope in a JSF project,then that would solve all of the difficulties that I was having with JSF as well. Additionally, there is pretty decent support for developing with JSF (e.g. IDEs, books, etc), which wasn't really there for Wicket. Finally, it seems to me that although when you work with Wicket, often times you might not have to even touch any html, it seems to me that when I do web development, sooner or later I would have to deal with html.
Luckily, at my job, I pretty much have choice of what framework or approach to use in developing the next application. Thus, I really don't have to learn any framework or approach that I don't think would be useful in the future or wouldn't be a good investment of time from all points of view. So, from the easiness point of view, Wicket does have a lot to offer. However, at this point, at least for me, from a "future investment" point of view, I think that investing more time into JSF would be more valuable.
JSF early adopter...
I know that I am not too early in the adoption cycle for JSF.. but it's funny, cause it feels that way.. I mean that I learned struts when it was already quite popular (although I think a little before it peaked in popularity), and there were already a good number of books, tutorials, etc. Not with JSF - there are a lot resources on how to do stuff, however, there is no "definitive" best practices that have existed with Struts in a while.. and so many different things just kinda seem half baked in JSF.. I mean, I understand that it was designed to have "tool support" and so on.. but really, there needs to be a package (e.g. maybe Shale) that would provide a layer on top of JSF that resolves the trivial and middle-of-the road problems in a nice way, just like Struts did the same for servlet programming.. I mean, before Struts, everyone was hacking out their own little solutions, and had their own way of dealing with http requests and responses, form submissions, validations, etc.. and now with JSF, there are a couple of different ways to solve the same problem..
Here is an example - dealing with row selection in an h:dataTable :
1. One possible way to solve it is to write a custom component, just like ibm did in this explanation . But really, how many people who don't use WebSphere would actually sit down and write their own component for that (especially considering that JSF components are notoriously difficult to do.
2. There was another post on the Sun JSF forums, where none other than CraigMcc responded to a question on how to do it (took a bit of digging
* Option#1 was to have a bolean property in the actual bean that you're iterating over, to indicate that the bean was selected. That is not very pleasant to use, as first, you might have to wrap your regular beans into a bean that has boolean property..
* Option #2 is to bind a datatable to the backing bean, bind a checkbox to the backing bean, and then on submit, actually iterate over the dataTable, and check the value of the h:selectBooleanCheckbox on each iteration . Now, this is pretty simple and straightforward, with the only downside that you definitely bind your backing bean to the JSF API (which is generally frowned upon, but then on 2nd thought, the backing bean is generally tied to the framework api anyways for whatever framework you're using). Now, the thing that kinda pissed me off was that after reading the two books that I mentioned in the previous post, I really had no clue that it would work that way - that the single checkbox that's bound into a single (not array) backing bean property, would change it's "selected" value based on how you iterate inside the h:dataTable .I kinda liked this solution the most.
3. In the appropriate column in the dataTable, include a verbatim html input checkbox. Then, when you're processing the submit in the backing bean, retrieve the request params with the same name as the checkbox, and you will get a string array with the checkbox values. Not a bad solution as you get everything you need, with the downside that you have to muck around with the request... (this option and a couple of other ones are discussed in more detail here
So, there it is.. there are a few different ways to solve this problem that should really be something trivial... and none of them are particularly straightforward....
Here is an example - dealing with row selection in an h:dataTable :
1. One possible way to solve it is to write a custom component, just like ibm did in this explanation . But really, how many people who don't use WebSphere would actually sit down and write their own component for that (especially considering that JSF components are notoriously difficult to do.
2. There was another post on the Sun JSF forums, where none other than CraigMcc responded to a question on how to do it (took a bit of digging
* Option#1 was to have a bolean property in the actual bean that you're iterating over, to indicate that the bean was selected. That is not very pleasant to use, as first, you might have to wrap your regular beans into a bean that has boolean property..
* Option #2 is to bind a datatable to the backing bean, bind a checkbox to the backing bean, and then on submit, actually iterate over the dataTable, and check the value of the h:selectBooleanCheckbox on each iteration . Now, this is pretty simple and straightforward, with the only downside that you definitely bind your backing bean to the JSF API (which is generally frowned upon, but then on 2nd thought, the backing bean is generally tied to the framework api anyways for whatever framework you're using). Now, the thing that kinda pissed me off was that after reading the two books that I mentioned in the previous post, I really had no clue that it would work that way - that the single checkbox that's bound into a single (not array) backing bean property, would change it's "selected" value based on how you iterate inside the h:dataTable .I kinda liked this solution the most.
3. In the appropriate column in the dataTable, include a verbatim html input checkbox. Then, when you're processing the submit in the backing bean, retrieve the request params with the same name as the checkbox, and you will get a string array with the checkbox values. Not a bad solution as you get everything you need, with the downside that you have to muck around with the request... (this option and a couple of other ones are discussed in more detail here
So, there it is.. there are a few different ways to solve this problem that should really be something trivial... and none of them are particularly straightforward....
JSF dirty little secrets
I've been working pretty intensively with JSF for the last couple of weeks on a couple of different projects. I usually read a couple of books before I dig into a technology in order to get a good understanding of how it works, how it does things, etc. So, a couple of months ago, I read 2 books on JSF, looked at a couple of tutorials, and gave it a shot. The first couple of apps were pretty straightforward, and since I never did anything particularly complicated, it worked OK. This time around, the sh*t really hit the fan.. Not that I was doing anything particularly complicated, but it was outside of the "really easy" stuff that is in all the tutorials and books... And all of I sudden, I started finding these "dirty little secrets" that each technology has, that one hopes to either never encounter, or to possibly be able to find a half-decent solution. I really would like to learn more about it, but I was surprised very unpleasantly to start hitting these roadblocks so early in learning about the technology.. I mean, JSF was supposed to make the developers' lives easier... and that is the case for 10% of the most trivial cases..
The other thing that really bugs me is the amount and depth of material that is covered in the JSF books that I have... ("Core JSF" and "JSF in Action"). I mean that it seems that the authors intentionally picked up examples that were in the 10% "easy" zone, where none of the ugliness shows.. I mean, I would have thought that in an effort to make their books useful, the authors would try to cover a few examples that go beyond the trivial stuff. Now, it's not like they don't show you any of the "advanced" stuff like building your own components.. they do, but the basic stuff is really so basic and they don't give examples or useful workaround to the middle of the road practical problems that one encounters...
I will go back to the example that I spent a lot of time on.. and I will try to post the problem, solution, and the explanation..
The other thing that really bugs me is the amount and depth of material that is covered in the JSF books that I have... ("Core JSF" and "JSF in Action"). I mean that it seems that the authors intentionally picked up examples that were in the 10% "easy" zone, where none of the ugliness shows.. I mean, I would have thought that in an effort to make their books useful, the authors would try to cover a few examples that go beyond the trivial stuff. Now, it's not like they don't show you any of the "advanced" stuff like building your own components.. they do, but the basic stuff is really so basic and they don't give examples or useful workaround to the middle of the road practical problems that one encounters...
I will go back to the example that I spent a lot of time on.. and I will try to post the problem, solution, and the explanation..
Tuesday, April 11, 2006
JBoss & Redhat : live happily ever after
I am also really still having a hard time believing that Redhat bought JBoss. When I first read the announcement, I thought that it was some kind of belated April Fool's day joke.. after all the rumours that were out there about Oracle buying JBoss (which was really giving the the chills - I was almost seeing how after 6 months, Oracle decides not to release JBoss as open source and slap some $50,000 license on it).
Now that I've thought about it... what JBoss and Redhat did makes a LOT of sense. I mean that they really seem made for each other , similar business model, similar razor sharp focus on the customer (and a similar desire to sign you up for their subscriptions :-) ). On the other hand, it makes me wonder what will happen to former JBoss partners like Novell/SuSE.. Apparently, they compete directly with RedHat, and so the question is whether they will continue working with JBoss.. Also, in the past, IBM pushed/distributed RedHat with their own J2EE offerings... but now that Redhat has their own J2EE app server, will that continue to be so.
Also, in retrospect.. I remember reading some stuff about RedHat specific J2EE framework... and then I was really wondering "Why in the world are they trying to re-invent the wheel by creating a new J2EE (JEE) framework that nobody knows about". Well, I guess that "I'll invent my own RedHat framework" garbage shall stop...
Now that I've thought about it... what JBoss and Redhat did makes a LOT of sense. I mean that they really seem made for each other , similar business model, similar razor sharp focus on the customer (and a similar desire to sign you up for their subscriptions :-) ). On the other hand, it makes me wonder what will happen to former JBoss partners like Novell/SuSE.. Apparently, they compete directly with RedHat, and so the question is whether they will continue working with JBoss.. Also, in the past, IBM pushed/distributed RedHat with their own J2EE offerings... but now that Redhat has their own J2EE app server, will that continue to be so.
Also, in retrospect.. I remember reading some stuff about RedHat specific J2EE framework... and then I was really wondering "Why in the world are they trying to re-invent the wheel by creating a new J2EE (JEE) framework that nobody knows about". Well, I guess that "I'll invent my own RedHat framework" garbage shall stop...
Opensourcing of Mobility Pack
World, take note, the Mobility Pack has been open sourced !!!! Awesome....
Opensoucing of Mobility Pack. Well, I can't wait to get my hands on the source code so that I can figure out why the hell the WTK 2.2 emulator would not play videos under Linux - it only shows a black rectangle, the media "pretends" that it's playing, but nothing is displayed. What would also be cool is that for my thesis presentation, I would be able to make an "Emulator connector" for the server side of my Mobile Video Streaming project, so that when the media becomes available, I can "send" a text message to the emulator directly from the server side (and not having to do stuff manually)...
All in all... AWESOME !!!
Opensoucing of Mobility Pack. Well, I can't wait to get my hands on the source code so that I can figure out why the hell the WTK 2.2 emulator would not play videos under Linux - it only shows a black rectangle, the media "pretends" that it's playing, but nothing is displayed. What would also be cool is that for my thesis presentation, I would be able to make an "Emulator connector" for the server side of my Mobile Video Streaming project, so that when the media becomes available, I can "send" a text message to the emulator directly from the server side (and not having to do stuff manually)...
All in all... AWESOME !!!
Friday, April 07, 2006
Netbeans Community Chat
Check out the first NetBeans chat - a lot of good ideas of what needs to be done in Netbeans, as well as a good feel of the important people around the development. Lots of good ideas from the chat and I'll be looking forward to seeing them : e.g. setting up a centralized wiki for NetBeans, setting up some RSS feeds about new documentation and stuff, setting up a centralized spot with useful update centers, etc.
Reading through the chat makes me think about something.. I do believe NetBeans is superior to Eclipse - seriously, I've tried to set up Eclipse on a few occasions (e.g. JBossIDE), but after the first hour of trying to install everything I need, I just give up.. In NetBeans, everything just comes in integrated very nicely. However, one thing that I think Netbeans is behind Eclipse is tool support for various projects - e.g. xdoclet tag completion (although there is a pretty good shot at creating a module), better hibernate support, etc. I do think that one of the reasons that a lot of people go for Eclipse is that it just has a little tool that supports what they're currently doing..
Something else that is NetBeans related that I just remembered - I was really bummed out when I found out that Nokia has moved their IDE to Eclipse (with carbidej and I guess carbideC+).. I was really happy to just install their Nokia Developer Suite and have some extensions to my NetBeans install...
Reading through the chat makes me think about something.. I do believe NetBeans is superior to Eclipse - seriously, I've tried to set up Eclipse on a few occasions (e.g. JBossIDE), but after the first hour of trying to install everything I need, I just give up.. In NetBeans, everything just comes in integrated very nicely. However, one thing that I think Netbeans is behind Eclipse is tool support for various projects - e.g. xdoclet tag completion (although there is a pretty good shot at creating a module), better hibernate support, etc. I do think that one of the reasons that a lot of people go for Eclipse is that it just has a little tool that supports what they're currently doing..
Something else that is NetBeans related that I just remembered - I was really bummed out when I found out that Nokia has moved their IDE to Eclipse (with carbidej and I guess carbideC+).. I was really happy to just install their Nokia Developer Suite and have some extensions to my NetBeans install...
Monday, April 03, 2006
wait for another month for e61
Now, Mobilebee says there are 17 more days until the e61 become available. This kinda sucks, since this is the 2nd or 3rd delay in a row.. It says 17 days, but who knows whether there isn't going to be another delay after that. And even if they do release is then, it's gonna be a few days until the handsets become available to Mobilebee, and then another couple of days until they ship it to me... Of course it's not their fault, Nokia was supposed to release it in Q1.. In summary, life sucks today..
On a related note, I am reading a book about developing for Series 60.. The first time I read through the first couple of chapters, I have to say that many of the concepts in developing for Symbian were quite difficult to grasp.. I did suspect that I've been living in Java land for too long, becoming almost complacent cause Java is so great (no seriously)... So, a lot of the things in how things were done in C++ on Symbian were not very clear.. I put the book aside for a couple of days, dove into "Thinking in C++" (thanks Bruce Eckel"), and several days later re-emerged and started reading the Series 60 book again.. The difference is huge, and now pretty much everything makes sense and is much easier to follow... I've only read the first few chapters of the book, but all in all, I like it a lot (it doesn't try to oversimplify things).
On a related note, I am reading a book about developing for Series 60.. The first time I read through the first couple of chapters, I have to say that many of the concepts in developing for Symbian were quite difficult to grasp.. I did suspect that I've been living in Java land for too long, becoming almost complacent cause Java is so great (no seriously)... So, a lot of the things in how things were done in C++ on Symbian were not very clear.. I put the book aside for a couple of days, dove into "Thinking in C++" (thanks Bruce Eckel"), and several days later re-emerged and started reading the Series 60 book again.. The difference is huge, and now pretty much everything makes sense and is much easier to follow... I've only read the first few chapters of the book, but all in all, I like it a lot (it doesn't try to oversimplify things).
Saturday, April 01, 2006
waiting for e61
In the next few weeks I'll be blogging about Symbian and the upcoming Nokia E61.
Up until yesterday, I was expecting mobilebee to show that the phone is available. It was initially scheduled to ship in Q1 2006; however, there are delays.. so it's still not available. So, yesterday, I called up mobilebee to check exactly what it means that there are 0 days until the phone becomes available. The customer service rep told me that they were expecting Nokia to announce the availability of the phone on Fri; however, nothing happened then.. So, they said that if the phone is announced on Monday, then I should be able to order it by mid-next week.. which means that I might have it in my hands sometime at the end of next week or the beginning of the week after.. I even though of maybe driving to NYC to pick it up on my own ; however, with their free shipping on orders over $300 (and the E61 is a whopping $499... )
Up until yesterday, I was expecting mobilebee to show that the phone is available. It was initially scheduled to ship in Q1 2006; however, there are delays.. so it's still not available. So, yesterday, I called up mobilebee to check exactly what it means that there are 0 days until the phone becomes available. The customer service rep told me that they were expecting Nokia to announce the availability of the phone on Fri; however, nothing happened then.. So, they said that if the phone is announced on Monday, then I should be able to order it by mid-next week.. which means that I might have it in my hands sometime at the end of next week or the beginning of the week after.. I even though of maybe driving to NYC to pick it up on my own ; however, with their free shipping on orders over $300 (and the E61 is a whopping $499... )
Subscribe to:
Posts (Atom)