It’s not common to do something with Java source code programmatically, but I find the javaparser project is very handy if such a use case comes up. It’s a Java 1.5 parser with AST generation and visitor support. With the API, you can access various elements in the source code like class, methods, statements, javadoc, comments, etc.
Java Collections APIs consists of well designed classes and interfaces for managing all sorts of data structures. With Java 8, there is a new enhancement called Stream API related to the Collection APIs (see What’s New in JDK 8). I spent some time to study the new feature last week as part of my effort to bring myself up to date with Java 8.
Coming with lambda feature in Java 8 is the method reference feature. It allows programmers to use methods as variables, and parameters to other methods. It works for class constructors too, where the method name is unanimously “new.’
There are four types of method references per Oracle documentation. Syntax wise, they all look similar with double colons as shown in the following sample code.
Following the last article about Lambda feature in Java 8, I spent some more time on other features and will blog about them along the way. It’s a good way to push me to really think through and thus deepen my understanding. This article is about default method which is in fact related to the lambda feature.
On last Tuesday (March 18, 2014), Oracle released the Java SE 8. Here is the official documentation from the company on the new features in Java SE 8, ranging from language itself, libraries, tool, and run-time.
As mentioned in my last post, Thrift is a cross-language and cross platform RPC framework. We’ve seen how a Java based Thrift server and client work there. Let’s take a look how to write a quick python script that connects to the Java Thrift server. It’s all possibe to write a Python based Thrift server, but probably not what most people want to do due to performance and scalability.
In one of my recent consulting projects, I had to use SSH from Python. After a little research, I ended up with using the paramiko package as library.
To download the paramiko package, just check out this link. What I downloaded was paramiko-1.12.0.tar.gz. After it’s uncompressed with 7-Zip to a temparary directory, just issue the following command and the needed library got installed into the site-packages directory.
Just started to work on hacking the Web application of vCAC and REST APIs in C#. As expected, the XML processing is an indispensable part for that purpose. I have worked on C# on and off in the past, but never as consistently as on Java. To get myself familiar with the related C# APIs for parsing, I coded the following sample code.
Unit testing is an important part of software development because it helps capture bugs before it moves on to QA or even customers. However, it’s not part of the end product therefore whatever you invest in unit testing will not yield any direct result but indirect result in better quality of your product. So at one side, you want to do it more for better quality; on the other side, you want to minimize it for less investment. It’s therefore a tricky trade off for best ROI. For more discussion, see here.
I just spent a little time playing with C# on password encryption. Here is a sample code I wrote to get myself familiar with related APIs. Overall it’s pretty straight forward – it first encrypts a clear text to an encrypted Base64 encoded string, then reverses it.
When a developer learns a new programming language or API, the first thing is probably to try out a HelloWorld sample. As said, real programmers don’t read documents. Although I don’t fully agree on that, it has some truth in it.
In my own experiences, I normally continue with other samples after HelloWorld one. When something is not quite clear, I check out the API reference or read some tutorials. Anyway, I am not telling you how to learn a new language or API, but trying to make a point here on the importance of code samples for the developers. In my opinion, samples are the most effective way to empower your users.
I think you would agree with me, there are too many bad samples. Here are some typical symptoms:
- Too much boilerplate code to a point that the code illustrating the API usage got buried. Typical boilerplate code includes extensive exception handling, GUI, logging, etc. Some samples even have a common library that could confuse your users totally.
- Too many API calls in one sample. You may need several APIs for a use case, but don’t aim one sample for multiple use cases.
- Too much object oriented. Object oriented programming is a best practice for application development. But it could confuse your developers sometimes.
- Dependencies on other APIs. To run the sample, your users need to install other libraries which may or may not need extra configuration or tuning. To understand the sample, users need to understand additional APIs. Extra burden, really!
- Of course, typical bad smells of programming which are not unique for samples. For example, bad naming, unnecessary global variables, using object attributes for passing values between methods, etc.
Now, how you can develop great samples? Besides the best practices writing great applications, you want to follow the following guidelines: