http://jsonlint.com/ - I use this to format and validate JSON I'm working with. Wonderfully simple and responsive interface.
http://json.bloople.net/ - A great tool to make exploring possibly large JSON data easier. Also useful for showing the content of JSON to a semi-technical audience.
https://github.com/FasterXML/jackson - Jackson is a fantastically flexible tool for working with JSON in Java. Jackson + Lombok make my API classes super trim and easy to enhance. I'll write a quick tutorial on this sometime.
Friday, November 22, 2013
Wednesday, November 20, 2013
Programming Tool Reviews
I'm a tools guy. With the right tools, hard jobs become easy. Finding good tools can be difficult and as time passes, the best tools for a given job change. I'll be writing posts here to document the tools I find and my experiences with them.
Thursday, August 16, 2012
A few quick lessons about Gradle, Jaxb, and XML
It surprising how much certain kinds of little roadblocks can slow you down. So I thought I'd mention my Gradle/Jaxb/XML woes of late in hopes they'd be helpful.
First, it appears as though the element name in XSD files is case sensitive in some tools and not in others. This means that when I took an (apparently functional) XSD and tried to run it through ant xjc (using gradle) it broke.
Java has a limit to the length of a qualified classname. According to stack overflow it is 64k. I never imagined I'd need to know that little factoid. But it turns out that one of my schemas has such a deep definition of types, that it exceeds this limit. The error warning isn't especially helpful.
Finally, I needed a feature in the jaxb plugin that wasn't available. So I implemented it. GitHub and the open ethic is amazing. It wasn't long ago when fixing adding a feature to a project on a whim would have been a serious undertaking. Instead, it was a pleasure to get my hands dirty and improve a project that had improved my project. That's the best kind of paybacks!
First, it appears as though the element name in XSD files is case sensitive in some tools and not in others. This means that when I took an (apparently functional) XSD and tried to run it through ant xjc (using gradle) it broke.
Java has a limit to the length of a qualified classname. According to stack overflow it is 64k. I never imagined I'd need to know that little factoid. But it turns out that one of my schemas has such a deep definition of types, that it exceeds this limit. The error warning isn't especially helpful.
Finally, I needed a feature in the jaxb plugin that wasn't available. So I implemented it. GitHub and the open ethic is amazing. It wasn't long ago when fixing adding a feature to a project on a whim would have been a serious undertaking. Instead, it was a pleasure to get my hands dirty and improve a project that had improved my project. That's the best kind of paybacks!
Friday, June 17, 2011
Gradle Sonar source compatibility
I'm slowly migrating a large project to Gradle. One of the major selling points is the Sonar plugin. I switched a module to Gradle and ran the 'gradle sonar' command. I got a screen full of exceptions that looked like this:
Fail to execute PMD. Following file is ignored:
I was building for Java 7. I did the obvious google searches and didn't find an answer. A bit more work and I found the solution here. Basically, I needed to add the following to my build.gradle file:
The important bit was this: 'sonar.java.source': '1.6'. Hope this helps someone =).
Fail to execute PMD. Following file is ignored:
/Users/spina/Code/apt/StagingGround/Utilities/src/main/java/gov/nasa/gsfc/util/VersionChecker.java
net.sourceforge.pmd.ast.ParseException: Can't use annotations when running in JDK 1.4 mode!
at net.sourceforge.pmd.ast.JavaParser.checkForBadAnnotationUsage(JavaParser.java:32)
at net.sourceforge.pmd.ast.JavaParser.MarkerAnnotation(JavaParser.java:5353)
at net.sourceforge.pmd.ast.JavaParser.Annotation(JavaParser.java:5272)
at net.sourceforge.pmd.ast.JavaParser.Modifiers(JavaParser.java:347)
I was building for Java 7. I did the obvious google searches and didn't find an answer. A bit more work and I found the solution here. Basically, I needed to add the following to my build.gradle file:
sonar {
// Tell sonar where the cobertura codecoverage reports are and what version of java to use.
projectProperties([ 'sonar.java.source': '1.6', 'sonar.dynamicAnalysis': 'reuseReports', 'sonar.cobertura.reportPath': 'build/reports/cobertura/coverage.xml' ])
}
The important bit was this: 'sonar.java.source': '1.6'. Hope this helps someone =).
Monday, May 9, 2011
What can I do?
I want to have a list of the skills that I have. This is to help me track my growth and may help me identify solutions to problems that I face in the future. Hopefully I'll update this occasionally...
1) Java - 3+ years professional experience as of 2011.
2) CVS - Version control.
3) Mercurial - Better Version Control.
4) Groovy - Writing a 'Domain Language' for external users (still not sure how successful I was)
5) Groovy Scripting - Shell scripting using a Java Dialect
6) JavaFx - A rendering language for Java. Needs better tooling.
7) Html - Through Notepad and WYSIWYG editors
8) Ajax - 1 graduate level class where I learned how it works.
9) Eclipse - A good IDE
10) Omnigraffle - A good diagram creation tool
11) Cosi - a listening infrastructure (developed by STScI).
12) Bugzilla - a bug tracking system.
13) Mylyn - a task management tool in Eclipse.
14) ant - build system
15) maven - better build system
16) gradle - even better build system
17) Sonar - build analysis
18) cobertura - code coverage analysis
19) jUnit - unit testing of Java and Groovy code
20) Objective c - initial implementation of an iPad app.
21) SVN - better than CVS
1) Java - 3+ years professional experience as of 2011.
2) CVS - Version control.
3) Mercurial - Better Version Control.
4) Groovy - Writing a 'Domain Language' for external users (still not sure how successful I was)
5) Groovy Scripting - Shell scripting using a Java Dialect
6) JavaFx - A rendering language for Java. Needs better tooling.
7) Html - Through Notepad and WYSIWYG editors
8) Ajax - 1 graduate level class where I learned how it works.
9) Eclipse - A good IDE
10) Omnigraffle - A good diagram creation tool
11) Cosi - a listening infrastructure (developed by STScI).
12) Bugzilla - a bug tracking system.
13) Mylyn - a task management tool in Eclipse.
14) ant - build system
15) maven - better build system
16) gradle - even better build system
17) Sonar - build analysis
18) cobertura - code coverage analysis
19) jUnit - unit testing of Java and Groovy code
20) Objective c - initial implementation of an iPad app.
21) SVN - better than CVS
Friday, October 29, 2010
Announcing Gradle-Plugin-JavaFx! JavaFx built by Gradle.
I complained earlier about how JavaFx is missing some really critical tooling. I mentioned debug support, and build support. In particular I was wishing that there was a JavaFx plugin in Gradle.
Because it was lacking and I really wanted FxBattle to build using Gradle. I decided to make such a plugin. Well, this is the official release of Gradle-Plugin-JavaFx version 0.1.0. I know, the name just rolls off your tongue.
It's an open source project that exists only to enable the FxBattle build. Still, others may find it useful. If they do, I'd love to hear from them. Keep up the great work Gradle developers. I love your product and am hoping to use it more widely soon.
Because it was lacking and I really wanted FxBattle to build using Gradle. I decided to make such a plugin. Well, this is the official release of Gradle-Plugin-JavaFx version 0.1.0. I know, the name just rolls off your tongue.
It's an open source project that exists only to enable the FxBattle build. Still, others may find it useful. If they do, I'd love to hear from them. Keep up the great work Gradle developers. I love your product and am hoping to use it more widely soon.
Tuesday, October 5, 2010
Why I love OkGo
This is a beautiful video. Their use of vivid color and clever production combines with their mellow, trance-like music to give a really excellent and somewhat trippy experience.
in reference to: YouTube - OK Go - End Love - Official Video (view on Google Sidewiki)Sunday, October 3, 2010
What do I want to see developed for JavaFx?
JavaFx is a decent language for coding a User Interface. The interface for FxBattle would have been a bear to write in Java. Other languages might be easier than JavaFx, but I don't know of any that run on the JVM.
====== Performance Debug Tools ======
When I started work on the FxBattle GUI, I discovered that there was little support for Eclipse (my preferred IDE) so I worked on it using NetBeans. This was fine until I managed to get NetBeans into some strange state where I couldn't really build the project. Not Good. A bit later, I discovered a terrible performance issue in the code.
I spent hours trying to track down the problem. I looked online for 'best practices' for JavaFx. What I found was advise like 'don't use too many bindings', 'make unused components invisible', and others. At JavaOne this year, I went to a talk on performance tricks. They gave similar advise.
The problem with this kind of advise is that they are asking you to hunt through your entire code base and do guess-and-check debugging. You're suppose to find a binding, ask the question 'Is this the problem binding?' Then you're supposed to find some way to implement your logic without bindings and see if it's better.
Imagine debugging performance in an enterprise application like this. Our database updates are taking too long... let's look through all our DB queries and change them one at a time to see if the process gets faster. Of course that's out of the question. Instead we use profiling software to help us find the performance problem.
I did use YourKit to profile FxBattle. It told me that most of the processing was spent redrawing the GUI. This was no surprise. The problem was, YourKit couldn't tell me what code was queuing up the redraws that were taking up the time. So I had to fall back to the guess-and-check debug system. This completely killed my progress. I was guessing that the problem was in the JavaFx core anyway, so I just waited for JavaFx 1.3. When it was released the performance of FxBattle was greatly improved.
====== Build Tools ======
Another reason I was working on FxBattle was to learn about build systems. The build for FxBattle is somewhat complex. Lots of subsystems, some of which are JavaFx, some use Protocol Buffers, some are Java, some are Clojure.
The first build system for FxBattle was Maven. I find I liked it better than I like Ant. It gives you more features in fewer lines of build logic. However, trying to get it to do anything it isn't already good at is really tough. There were no tools to build JavaFx, Clojure, or Protocol Buffers. Getting a sensible build put together was a real bear.
Given that Maven is a very popular build system, why wouldn't there be a plugin to build JavaFx already available? On top of that, I had Java Code which tried to invoke JavaFx code. Doing this required the JavaFx Runtime Jars on the classpath. So I should be able to specify a dependency in my POM that makes those Jars available. Nope, can't do that. The Jars aren't allowed in the Maven Central Repo. Why? Doesn't SUN (now Oracle) want people to develop JavaFx apps? Doing that means we have to be able to access the Jars during our build process.
At JavaOne this year, I decided to try rewriting the build to use a new build technology called Gradle. I'm nearing completion of this task. I really like Gradle.
I was surprised to find that there is already a plugin for Clojure and Protocol Buffers. Great! That makes the build much simpler. Though it did take a while for me to figure out how to hook them all up.
Okay, got the back end compiling, now it's time to compile the front end. Where is the JavaFx plugin for Gradle? There isn't one? There is a lot of hype around JavaFx, but an up-and-coming build system doesn't already have a plugin to compile it?
So, I wrote a plugin for Gradle that compiles JavaFx. It is based on Clojuresque and appears to do the job for my use case. I will probably publish it once I hear back from a few people that there isn't already a tool that does this job.
===== Summary =====
We need to be able to debug JavaFx performance.
We need to be able to build JavaFx in all the popular build systems.
Better Controls, CSS, and other such features aren't useful if we can't do the above.
====== Performance Debug Tools ======
When I started work on the FxBattle GUI, I discovered that there was little support for Eclipse (my preferred IDE) so I worked on it using NetBeans. This was fine until I managed to get NetBeans into some strange state where I couldn't really build the project. Not Good. A bit later, I discovered a terrible performance issue in the code.
I spent hours trying to track down the problem. I looked online for 'best practices' for JavaFx. What I found was advise like 'don't use too many bindings', 'make unused components invisible', and others. At JavaOne this year, I went to a talk on performance tricks. They gave similar advise.
The problem with this kind of advise is that they are asking you to hunt through your entire code base and do guess-and-check debugging. You're suppose to find a binding, ask the question 'Is this the problem binding?' Then you're supposed to find some way to implement your logic without bindings and see if it's better.
Imagine debugging performance in an enterprise application like this. Our database updates are taking too long... let's look through all our DB queries and change them one at a time to see if the process gets faster. Of course that's out of the question. Instead we use profiling software to help us find the performance problem.
I did use YourKit to profile FxBattle. It told me that most of the processing was spent redrawing the GUI. This was no surprise. The problem was, YourKit couldn't tell me what code was queuing up the redraws that were taking up the time. So I had to fall back to the guess-and-check debug system. This completely killed my progress. I was guessing that the problem was in the JavaFx core anyway, so I just waited for JavaFx 1.3. When it was released the performance of FxBattle was greatly improved.
====== Build Tools ======
Another reason I was working on FxBattle was to learn about build systems. The build for FxBattle is somewhat complex. Lots of subsystems, some of which are JavaFx, some use Protocol Buffers, some are Java, some are Clojure.
The first build system for FxBattle was Maven. I find I liked it better than I like Ant. It gives you more features in fewer lines of build logic. However, trying to get it to do anything it isn't already good at is really tough. There were no tools to build JavaFx, Clojure, or Protocol Buffers. Getting a sensible build put together was a real bear.
Given that Maven is a very popular build system, why wouldn't there be a plugin to build JavaFx already available? On top of that, I had Java Code which tried to invoke JavaFx code. Doing this required the JavaFx Runtime Jars on the classpath. So I should be able to specify a dependency in my POM that makes those Jars available. Nope, can't do that. The Jars aren't allowed in the Maven Central Repo. Why? Doesn't SUN (now Oracle) want people to develop JavaFx apps? Doing that means we have to be able to access the Jars during our build process.
At JavaOne this year, I decided to try rewriting the build to use a new build technology called Gradle. I'm nearing completion of this task. I really like Gradle.
I was surprised to find that there is already a plugin for Clojure and Protocol Buffers. Great! That makes the build much simpler. Though it did take a while for me to figure out how to hook them all up.
Okay, got the back end compiling, now it's time to compile the front end. Where is the JavaFx plugin for Gradle? There isn't one? There is a lot of hype around JavaFx, but an up-and-coming build system doesn't already have a plugin to compile it?
So, I wrote a plugin for Gradle that compiles JavaFx. It is based on Clojuresque and appears to do the job for my use case. I will probably publish it once I hear back from a few people that there isn't already a tool that does this job.
===== Summary =====
We need to be able to debug JavaFx performance.
We need to be able to build JavaFx in all the popular build systems.
Better Controls, CSS, and other such features aren't useful if we can't do the above.
Monday, September 27, 2010
Google Sidewiki entry by Andrew
I was looking for this to help me assemble my assignments for my AJAX course. I had lots of code and html files that I had to assemble into a PDF for turn in. This made it much easier!
in reference to: Automator Tip of the Week #3: Convert Word Documents to PDF | Mac Help from Maciverse (view on Google Sidewiki)Friday, September 24, 2010
FxBattle will be built by Gradle
One of the hold ups with FxBattle was JavaFx 1.3. When that was resolved, we'd forgotten how to build the system. It took a night at JavaOne to get it running again. We can build and run now using Fx 1.3 (which is WAY FASTER- YEAH!).
However, it's a big old hacky system and I don't like it. I used Maven, but lack of documentation, and severe rigidness were sufficient to make me want to abandon the technology. At JavaOne I learned about Gradle. It's a different kind of build toolkit.
I'm finding that I like it immensely. It is somewhat immature right now, but the activity surrounding it seems huge. The documentation is surprisingly complete for a product that isn't even version 1.0 yet. I've had some trouble getting plugins working in version 0.8. It required a bit of hacking and wasn't particularly strait forward. This said, 0.9 will have a much better plugin system (just drop a Jar into your system). There also appear to be plans for a plugin repository in the future so you can just ask for it by name.
I don't see a plugin for Gradle which builds JavaFx. If the plugin development documentation gets better, I may start such a plugin. At least, we'll have to be able to build JavaFx in FxBattle through Gradle.
However, it's a big old hacky system and I don't like it. I used Maven, but lack of documentation, and severe rigidness were sufficient to make me want to abandon the technology. At JavaOne I learned about Gradle. It's a different kind of build toolkit.
I'm finding that I like it immensely. It is somewhat immature right now, but the activity surrounding it seems huge. The documentation is surprisingly complete for a product that isn't even version 1.0 yet. I've had some trouble getting plugins working in version 0.8. It required a bit of hacking and wasn't particularly strait forward. This said, 0.9 will have a much better plugin system (just drop a Jar into your system). There also appear to be plans for a plugin repository in the future so you can just ask for it by name.
I don't see a plugin for Gradle which builds JavaFx. If the plugin development documentation gets better, I may start such a plugin. At least, we'll have to be able to build JavaFx in FxBattle through Gradle.
Tuesday, September 14, 2010
Learning AJAX
Turns out that you should know JSP before you start learning AJAX. Well, looks like I get to learn both together. Just started night school for a Masters in CS. I think it'll be interesting, but I have some trepidation about time constraints. It should help that APT is going to freeze soon so that I won't be under as much pressure to deliver the outstanding bug fixes/features.
Friday, July 2, 2010
Learning Groovy
Groovy looks like a cool thing to know. It looks like it's strictly better than Beanshell. It's a JVM language which is a superset of Java. I'm not planning on using any part of it except that it allows dynamic execution of java code. How cool! I'm expecting to author a scripting language in Groovy that will act as an controller for our application. It's been really easy to setup so far and I like it.
Sunday, May 23, 2010
Wednesday, May 19, 2010
Objective C lesson
After a fair amount of debugging on iD20, I discovered the following. If a UIView (or any other graphical container) has the property 'User Interaction Enabled' set to NO (or FALSE) then it, as well as it's children won't receive any touch events. So don't put your custom component inside of a parent that is blocking touch events.
Friday, April 23, 2010
Crows, the new and improved Ape
Pretty amazing - Crows can combine tools to solve problems.
http://news.sciencemag.org/sciencenow/2010/04/clever-crows-complex-cognition.html
Even cooler? Crows use features of the urban landscape to access food they wouldn't otherwise be able to eat:
http://www.youtube.com/watch?v=BGPGknpq3e0&feature=related
http://news.sciencemag.org/sciencenow/2010/04/clever-crows-complex-cognition.html
Even cooler? Crows use features of the urban landscape to access food they wouldn't otherwise be able to eat:
http://www.youtube.com/watch?v=BGPGknpq3e0&feature=related
Thursday, April 22, 2010
JavaFx 1.3 released!
17 days after giving up on Java 1.3, it's been released. I may try and migrate FxBattle to 1.3 just to see how the performance goes. If it's much better then perhaps I'll put some work in and polish it up. If I do that, I'll be sure to update here on what the results were.
So far, Objective C is going okay. It has some really nice APIs that just work. The learning curve hasn't been too tough, but I'm far from having a sense of what is elegant and what is ugly. Working with G and R will be fun. I'm looking forward to binding together the Persistance, Import, and Presentation layers and seeing what we come up with.
So far, Objective C is going okay. It has some really nice APIs that just work. The learning curve hasn't been too tough, but I'm far from having a sense of what is elegant and what is ugly. Working with G and R will be fun. I'm looking forward to binding together the Persistance, Import, and Presentation layers and seeing what we come up with.
Monday, April 5, 2010
Abandoning Fx 1.3 for Objective C (iPad for the win!)
So after waiting most of a year for JavaFx 1.3, I'm tired of waiting (as mentioned before). FxBattle is officially on the back burner when Fx 1.3 comes out I may give it another chance, but no guarantees-- I'd rather write something fun on a working and used infrastructure. So what will I be doing?
I talked to my partner in side projects and we're writing an iPad app. Yup, I'm on a whole new band wagon. But this one isn't going to stagnate for the next 10 months. This one is going to be a party (and I hear there's going to be a band).
But what will this new genius app do? It's going to be a very simple tool to help run grid based games like D&D. We'll model a map and markers on that map. Markers can represent monsters and heroes. The map will be grid based and support 'depth'. That's going to be roughly the minimal set of features for the first result.
Later we'll want to add lots of things I'm sure. But for now that should be enough features to be useful for our D&D group. So now all I need is the SDK. But guess what? The newest version won't run on Leopard (my current OS) and the old versions appear to have been nuked. All I want to do in brand myself, why won't Apple(tm) help?
UPDATE: Haven't tried this yet, but found a blog post with direct links to old versions of the iPhone SDK (including versions that will run on OSX Leopard and others).
I talked to my partner in side projects and we're writing an iPad app. Yup, I'm on a whole new band wagon. But this one isn't going to stagnate for the next 10 months. This one is going to be a party (and I hear there's going to be a band).
But what will this new genius app do? It's going to be a very simple tool to help run grid based games like D&D. We'll model a map and markers on that map. Markers can represent monsters and heroes. The map will be grid based and support 'depth'. That's going to be roughly the minimal set of features for the first result.
Later we'll want to add lots of things I'm sure. But for now that should be enough features to be useful for our D&D group. So now all I need is the SDK. But guess what? The newest version won't run on Leopard (my current OS) and the old versions appear to have been nuked. All I want to do in brand myself, why won't Apple(tm) help?
UPDATE: Haven't tried this yet, but found a blog post with direct links to old versions of the iPhone SDK (including versions that will run on OSX Leopard and others).
Saturday, March 27, 2010
Tired of waiting for Javafx 1.3
I understand the desire of Oracle to wait to release the next and most pivotal release of JavaFx until they're sure it ready to go. However, I started using Fx at JavaOne 2009. It was a neat tool and a chance to really engage myself at the conference.
A friend and I started writing a video game (FxBattle) that used a bunch of new and interesting Java technologies. We had a multi-threaded server running on Clojure. We used Google's Protocol buffers for our socket level communications. JavaFx was our tool for the client front end and we were using an in house tool called the CoSI to manage dynamic listening between the Fx Client and the Java based client data model.
The development process was very quick and agile for a while. Then we ran the game. The client was brutally slow. This taught me how to hook an Eclipse debugger into a remote process and then how to hook YourKit into a JavaFx app. I believe the slowness is an issue with Bindings causing redraws more frequently than they should.
I could work around this issue, but I'm told that Soma (Fx 1.3) will fix it. When I learned this (several months ago) Soma was to be released in short order. Where is it? I've been thinking that maybe the front end would see more players if I wrote it in Flash. Then at least I'd be learning a technology that was sure to have a future...
A friend and I started writing a video game (FxBattle) that used a bunch of new and interesting Java technologies. We had a multi-threaded server running on Clojure. We used Google's Protocol buffers for our socket level communications. JavaFx was our tool for the client front end and we were using an in house tool called the CoSI to manage dynamic listening between the Fx Client and the Java based client data model.
The development process was very quick and agile for a while. Then we ran the game. The client was brutally slow. This taught me how to hook an Eclipse debugger into a remote process and then how to hook YourKit into a JavaFx app. I believe the slowness is an issue with Bindings causing redraws more frequently than they should.
I could work around this issue, but I'm told that Soma (Fx 1.3) will fix it. When I learned this (several months ago) Soma was to be released in short order. Where is it? I've been thinking that maybe the front end would see more players if I wrote it in Flash. Then at least I'd be learning a technology that was sure to have a future...
Monday, February 22, 2010
Cool Twitter-like App
The article is somewhat fluffy for my tastes, but the content is great. I'd love to have a tool which tells me what competing bargains are across the street from the restaurant I'm considering. I just hope that it's spam resistant...
in reference to: Big City - Beyond Twitter - An App That Lets You Truly See City - NYTimes.com (view on Google Sidewiki)Monday, January 18, 2010
Interesting and True.
As a (relatively new) developer I agree with this unequivocally. It is nicely language neutral, so you can read it as a Java Developer (like me) or a PHP script master (definitely not me).
in reference to: 20/20: Top 20 Programming Lessons I've Learned in 20 Years - DCS Media (view on Google Sidewiki)
Subscribe to:
Posts (Atom)