Tag Archives: books

Apache Wicket [In Action]: A Review and How It Relates to the Java World

Posted by on 30 April 2013 No comments

Java is a great tool for creating software. It is well designed, modular, has a wide array of platforms that it can run on, performs well, it’s very extendable, and it has a large community with lots of support. However, it’s support for websites and related services is severely lacking. It’s bad enough that frameworks that extend the existing infrastructure have massive pitfalls that you later discover.

For the most part Apache Wicket solves many of the web related issues that J2EE (JSP) has. If you are to follow the prescribed way of doing things, it can actually be quite pleasant. However, there are a few thorny patches with Wicket. I will get to those later.

Wicket In Action like a marriage. During the honeymoon, everything is great. Everyone is happy, and then later discontent grows and things go up and down. However, unlike a marriage, you don’t really get an ending. This is a rather good way to end things, but some of the lesser parts of the book were rather disappointing. One of the big selling points of Wicket is that it is a framework that assumes that the developer has already prototyped the pages in HTML prior to starting with Wicket [The pages are adapted into Wicket-ized and previewable pages]. This upside was enough to ignore the placement of the HTML files, in the class path rather than the web resources section.

I jumped into this book with lots of enthusiasm after reading the introduction. I even bore through some of the non-stated setup issues in the book. The book starts off by creating a project, from scratch, however I went the Maven route (which I discovered is the better way to go). The book mentions maven, but it doesn’t mention how to build your application or to generate a project. I believe that I went the correct way because Maven helped to setup all of the application servers and the folder structures. The book started by having the user to jump in, examine a few code segments, and then to start on a sample (full featured) e-commerces application. The store was oddly pleasant; the goal was to sell cheeses online. The application started from a few sample view pages, it went on to creating a reusable shopping cart, and finally on to a membership mechanism. This is a very straightforward and to-the point way of starting a new framework. It’s already addressing the needs of the majority of its audience.

Another nice thing to point out about the introduction is that it did not try to cover all of the material at once. It would frequently describe what you were doing, but would mention the chapter where the concepts were explained in depth later on. Something that pleased me was that the code listings did not include a listing number. They were place in the correct location of the text. After you’re done with the sample application, you should be quite proud of yourself. This is similar to your first website.

However, the book got a little disappointing when describing the more detailed interworkings of Wicket: sessions, bookmarkable pages, and layering/rendering. The book improves when it gets to the Ajax functionality and a brief mention of dependency injection and Wicket. The book gets a little rough in the Spring through Hibernate sections and then better in the testing section. The book ends in a rather low note on SEO, production configuration, and JMX. If I had known more about JMX, I would have probably had a better opinion of the ending.

Overall I am not sure if I can say that the less than stellar sections of the book were entirely the authors’ or the book’s fault. It quite possibly may be the technology’s fault.  I would strongly recommend the book if you are new to Wicket.

Lastly, here are some direct tips that I had to discover on my own that helped out a lot:

 

Review: The Java Virtual Machine Specification: Second Edition (Java 2 Platform)

Posted by on 8 February 2013 Comments Off

Despite the age and subtitle. This book is still relevant for the Java 6 and 7 platform. The Java Virtual Machine Specification,by Tim Lindholm and Frank Yellin, is a specification book from a pre-Oracle time. The book goes over how the Java language is structured and designed. This is a great guide for any serious Java developer. The book provides insight on the reasons why things are designed the way they are, Java [assembly like] byte code, the classfile format, and a handy reference for the bytecode [including the op codes].

I read this book for non-professional reasons. It was more of a curiosity to read this book. At times, the book went into more detail than I cared about. Also, I skimmed over the documentation on the bytecode. However, I really did like that it introduced the detailed bytecode documentation and then followed it up with examples of how code is transformed into its related bytecode.

Reading this book should make Java Performance (Hunt) a bit easier to read, understand, and more interesting. That is when I can get to reading the book. At the moment, I have more than 30 [physical and non-physical] books on my reading queue.

Groovy in Action: A review

Posted by on 15 January 2013 2 comments

Groovy in Action is the book that I should have put down quite a long time ago. However, I did trudge through it. Most Manning Press “In Action” books do a good job at introducing basic concepts at the beginning, and then go into blinding detail near the end. “Hibernate [3.0] In Action” is a very good example of this.

However, “Groovy in Action” is annoyingly different.I have wanted to learn and use Groovy for quite a while. It’s a Java-based language, which uses the JVM, and comfortably interacts with all of your other Java libraries, and frameworks. With most books, which are responsible for introducing someone to a new language/framework, I expect the resource to really sell the language/framework in the beginning, and ease into the more gritty details. However, this book tried to do this at some points of the book, but lacked order.

The start of the book introduced the user into how to setup their environment and to create a few sample to get your feet wet. There was a very brief overview on what Groovy is able to do. However, after the brief overview, the book’s Part 1(pages 27-227) section becomes a reference book. Part two (228-451) started off nicely, but quickly became tiresome (mostly due to the strenuous task of the first part of the book).The third section was where the book really got interesting: going over how to apply Groovy to solve problems that you may run into. I liked the last section the best.

As a developer, my interest is in solving problems. I enjoy learning about advanced features and details of a language; however, a language/tool/framework is a means to solve a problem. If the tool/language/framework really piques my interest to use it more than once, I’ll go into more detail with it. This book would be better suited for someone that has already developed a strong interest, and would like a reference manual.

Review: “Test-Driven Development” by Kent Beck [The creator of JUnit]

Posted by on 24 May 2012 1 comment

It is always interesting to read a book about a technical topic from its creator. They tend to better identify the motivating factors and history that went into creating the product than other authors could possibly try. Kent Beck is the creator of JUnit, and happens to be the author of this book. The book is designed for people who are new to unit testing and Test-Driven Development. For anyone in the current software development industry, this is very few people.

The book is divided into three separate sections. The first being a walk-through with JUnit (by example), xUnit, and then a “best practices guide.” The JUnit section, the majority of the content of this book, is focused on developing a currency class. While there were some interesting design decisions, this part irritated me the most. The first section produced blatant errors, just to create a test that would fail. I would have preferred if these errors had been described rather than presented to the reader. The currency example was a good example, however adding another example would have been better. The xUnit section of the book focused on creating a test environment for Python. I am not a Python developer, but I have written a very small amount of code. I was not a fan of this section. However, I was pleased with the best practices section. The only issue I had with the last section is that I do not recall that the best practices section went into why the recommendations are better than what they replace. If my memory serves me correctly, it did not.

This is a great resource for developers who have never heard of TDD. It may even be a great book for students that have just completed half of a class in Java. However, it is not such a great book for people who have worked with Test Driven Development.  For those who have already worked with TDD, a Manning Press’s “In Action” series may be more suitable. Although their resource on JUnit looks to be a bit dated. Manning Press’s dated JUnit book includes information on integrations with other frameworks, which are slightly harder to test against [J2EE, XML, Servlets, EJB, DBs....].

In summary, I was probably looking for another book similar to “Pragmatic Unit Testing in Java with JUnit” (Hunt and Davis). Their approach was more focused on how to try to find trouble spots, and improve existing code.

Given that this was written in 2002, the following is not exactly fair criticism, but it should be mentioned by anyone that is claiming that TDD is beneficial. I would have liked to see more support [research/studies] on why Test Driven Development is beneficial. Every TDD-related article/publication/book that I have read always attempts to convince the reader that it’s necessarily with marketing-speak. The claim is that it is good for “high stress environments,” or it reduces defects. However, I have never seen evidence supporting the claim mentioned. I, personally, have found that TDD to be a significant improvement in development. However, I have never been able to quantify how much of an improvement it has made. What is the amount of time saved by TDD? Has it made today’s software more reliable than before? Has it affected the developer job market? [Increased/Decreased] Has it made the users of the products using TDD happier? Most importantly, has test-driven development reduced the stress of software development?

Computer Science Classes I Would Like To See Offered

Posted by on 25 April 2012 13 comments

My friend Warren recently expressed a very “scorched earth” opinion of the standard Computer Science curriculum. He suggested that given the available of free CS courses (OpenCourseWare and the like) and experts at your fingertips (Blogs and Stackoverflow); wheres the value of a formal CS degree?  That lead me to think …. What are some classes that would be very interesting to take: [Even as an alumni of 2 CS programs, I would be interested]

  • Software Development Tools: A lot of classes mention tools, but not how to actually use and extend them. [Build systems, version control systems, formatters, emulators/virtualization]
  • Debugging: The goal of this class is to teach basic skills and then go through labs of finding/fixing bugs. Later, to write unit tests to verify the bugs.
  • Testing software: This would be a hands-on class to teach students how to write unit tests, implement mocks, test black box software, and write up reports on testing procedures. This would also the involve testing of embedded hardware and software, black box systems, functional languages, network services, concurrent software, and even components that lack a stable test environment.
  • Computer Vision: It’s just interesting, and visual, often you don’t hit this class until graduate school.
  • How to design an API/Surveying APIs: Let’s get rid of bad APIs. This would also be responsible for demonstrating the differences [good and bad] of available APIs.
  • Open Source: Not really a history of open source. But this is to take an open source project, and extend it. The goal of this project is to get students involved with working with one project, and demonstrating improvement to the project.
  • Marketing: How to market your work, or someone else’s software. This isn’t designed to replace developers with marketers, but it just helps the developer understand how their work is sold.
  • Automation: How to automate manual tasks with software. This could be with build scripts, batch scripts, testing automation software, or even simple system scheduling.
  • From hardware to software: The goal of this class would be 2 things. To create a small embedded device, and then go all the way up the chain to a working software client. This would involve writing a device driver, interfacing with hardware ports, and using the driver. The second part of this class would involve creating a simple processor either as a circuit or a manual build. http://blog.makezine.com/2009/10/03/building-a-cpu-from-scratch/
  • How Computer Science relates to [Field x, y or z]: This is more of an open ended suggestion. For example: Offer a class on Bioinformatics [It’s a class that combines biology, and computer science], combine a class on art and computer science (that’s more of visualizations though), history and CS [examine potential DSLs involved with history research], or even math and CS [shows the tools, and libraries that one can use in their application].
  • How to crack software/re-engineer a binary: [Probably with the permission of the publisher] Crack a copy protection system. Many students know about software cracks, but very few actually know how to create them or how they work. The goal of this class would to familiarize the student with how software is compiled, and can be reworked after compilation. Also, this would demonstrate how to protect their application as well.
  • Alternative Language Survey: Yes, this is technically a standard class. But I’d like to see one on functional languages, Groovy, BF, or even creating your own domain specific languages be taught.
  • Community Service: This really isn’t as altruistic as the title may imply. This is more of a class to create a software component [as a large group] for a member of a local community. This could be a small interesting game [example I worked with a group for a class], or working with a small company or individual to improve or sofware-ize their product. Elon’s CS department did this a while back with the game deflection. even taking an existing board game [with the original creator] and making  a software version. The goal of this class is to research market need, create something usable and getting their fellow peers involved in using it. This would help communicate to the rest of the students about some of the cool things that CS can produce.
  • Author selected: Get an author of a quality software related book to teach a class. Have John Skeet teach a C# class. Paul Graham teach a class on LISP. Brian Goetz to teach a class on Concurrency.
  • Hands on Software Optimization class: Take an open source system, and optimize it. This class would teach formal procedures on how to optimize an existing application to perform as quickly as possible, monitor, and document the improvements.

Last of all, these classes should be fun and engaging. If you’re not actively involving the student, don’t even bother trying these suggestions.

Lost the Passion for Software Development?

Posted by on 10 April 2012 1 comment

This is a list of potential tips to help a fellow Software Engineer recover passion in his or her work:

  1. Learn A New Language: Stuck with working solely in Java and C++ languages? Learn Erlang, or Lisp. Try out Scheme, Perl, Bash, Haskell, or D.
  2. Learn a New Framework: Some of the frameworks to learn: xUnit, Testing frameworks [other than JUnit], Spring.net, Apache Tapestry, XMPP, Esper (Complex Event Processing), OpenGL, JasperReports, OpenCV, Win32, OSGi, or even Hessian binary web services.
  3. Revive old projects by refactoring the code to use a new framework. Review code in open source projects.
  4. Attempt to become an expert in an open source project. You might become an authority on the subject, and write a book.
  5. Meet new developers. To do this, branch outside of your company and go to user groups related to the language. JUG for Java groups, LUG for Linux user groups, NUG for .NET user groups etc.
  6. Read and listen to lectures on InfoQ.
  7. Take a “Thirty Day Challenge” by coming up with a complex application and writing it in a completely unfamiliar framework or language. Something that would be rather unique, write a web application completely in Prolog or Erlang. I haven’t heard of anyone that has done that yet, but it would be rather interesting.
  8.  Annoyed with an application, language or framework? Fix it. If it’s open source, then write a fix for it and publically submit a patch. If it’s due to a closed source application, then rewrite the main interface [if it connects to a backend service], or rewrite the application completely.
  9. Have a business idea? The book “The Lean Startup” suggests that startup-interested developers should create a stripped down demo, to gauge market interest.
  10. Add new “favorite tags” to your StackOverflow account. Look for questions that contain lots of votes. Look for questions that have not been answered in a long time, research a solution and answer the question.
  11. Find ways to make your current job/task easier. If you are spending a lot of time writing the same type of unit tests over and over again, find a way to automate this, or write your own domain specific framework. Even better, write a Domain Specific Language for the current development project.
  12. Use coverage tools to find new places to test code that is currently untested.
  13. Read research papers. This is typically a very dull task, but there are some quality papers available. It takes some effort to find those papers, but the ones that are well written are worth ones effort.
  14. Hack: [I'm not responsible for unethical/illegal actions, I would suggest doing these things only for personal interest] Setup a VM to learn how to exploit system services, learn how to perform a privilege escalation, learn how to write a buffer overflow and run shell code, learn how an intrusion detection system works and attempt to exploit them, and attempt to crack legally obtained software.  [I advise that the reader do these things ethically (don't share a software crack). The reader is responsible for his or her own actions. ]
  15. “Hack Hardware”- Write an application that interfaces with an Ardinio device. Root an Android or Apple phone.  You could also go the route that Linus Torvalds went, take data from existing devices and write an application that interprets the data. His project is SubSurface, its designed to take the data from a dive-computer, and to transform it into something the user can add notes to, and visually interpret the data. Write software for an embedded processor (FPGA, Basic/Java stamp).
  16. Learn how to make your own operating system. Take a Gentoo distribution, and reconfigure everything. Try out a real time Linux distribution.
  17. Look for project suggestions on Stackoverflow. There are quite a few questions from students asking about project ideas.  One popular suggestion is to write a plugin for a popular game. From my understanding, one can write a plugin for Civilization 4 by using Python.
  18. Find ways to make your job more fun, or easier. Identify tasks that are uninteresting or tedious and find a way to automate them. Learn how to configure and/or extend a build tool. Learn Ant, Maven, or Gradle.
  19. Take a vacation: Over-working one’s self is not an achievement, no one is impressed.

Lastly, (This really isn’t considered to be a tip) to help connect with others who have a similar interest to what you’re doing, write about your attempts, successes, or failures in a blog. Even if you decide that your current job is not fulfilling, then these are things that you can mention on your resume or future employers can see on your blog.

You’re a developer, as a developer you have the unique ability to create things. There is very little holding you back from developing something you want.

Have I missed some important tips? Have these tips help you? Are there any languages or frameworks that one should study? If so, leave them in the comments box.

Suggestions for Authors of Technical Books

Posted by on 29 March 2012 Comments Off

If you are writing about something that has to be installed on the reader’s machine there has been something that has become annoying. Please do not provide distribution based instructions for installing the software/component/framework. I would prefer it if this was listed on the book’s website, or linked to the platform/distribution’s website. In place of the section, I would prefer a brief history of the component that the book requires. For example, if the framework’s API was forked from another project, if the API would have been motivated by particular problems, and/or who uses it.

Having a website for the installation and configuration would allow it to be updated when the software gets changed. For example, if there was a major break in the API usage, the website could be updated and the user could be warned against using future versions.

Review: “Fooled By Randomness” by N. Taleb

Posted by on 22 March 2011 Comments Off

“Fooled by Randomness” is a book about the negative consequences of a dynamic financial market. More specifically, the book’s focus is due to the lack of a balance criticism of the potential negative outcomes and the evaluation of performance in the market.

There are some main features of the book that could be considered to be strong points. One of them being the topic of the book, compared to the neighboring books in its genre. The book attempts to debunk the hype surrounding popular strategies as being luck rather than an effective strategy. Another strength this book accounts for is randomness. It mentions that randomness may account for many successes that individuals attribute to events. Lastly, I must commend the author for advising the reader to stay out of short term markets. Short term markets are highly volatile and are not for individuals who cannot afford a loss.

Despite the redeeming qualities, “Fooled by Randomness” has a fair amount of distracting and vexing issues. Mainly the issue is with a personal bias. The author speaks with the reader in parts of the book and brags about how everyone is foolish not to see his point of view. For example he describes a radio debate, in which the radio host is talking with him about how a market downfall caught investors who had not properly considered the risk. His retort in the book was that he had been warning “these investors” for years.  This strikes me as rather off putting and ineffectual to put in the book. Assuming he has been issuing warnings, shouldn’t one consider the lack of response as an indicator of ineffectuality’s in communication?

Halfway-through the book I started to wonder: “Who is the target audience of this book?” Earlier in the book, while he is bragging, it’s obvious that he is targeting serious day traders and employees of investment groups. However, later in the book he attempts to debunk the effectiveness of these people. For example:  For brokers he claims that the people with a history are merely people who had gotten lucky. For analysis, they were merely lucky that history had a tendency to repeat itself. For academics, their work was really only good for the time period that they were in, and that it was too little too late (complex systems researchers).  I was quite shocked about his dismissal of Complex Systems Researchers. Typically Complex Systems advocates promote the idea of randomness influencing the system, and they can account of it.

Lastly, this book leaves me with the question:

If people are able to consistently make money on the market, then how do you successfully evaluate performance? His arguments attempt to ignore performance and claim that everything is merely luck.

Related Posts Plugin for WordPress, Blogger...
Better Tag Cloud