After two years of development a new version of VoucherTool was released today. With the performance improvements realised with this release the vision of VoucherTool serving as a core telecommunications grade component generating batches of tens to hundreds of millions of vouchers becomes a reality.
Key enhancements include:
- Significant performance improvements
- A free unique code generator for generating and downloading up to 1000 unique codes
The latter was included since using the SOAP API, released last November, is an investment. I wanted to see the tool being used and tested rapidly and the unique code generator is one way to do that.
In my opinion the role serves as an essential counter weight, and by that I mean a counter weight to short term profit oriented actions in software development projects that end up killing long term profitability.
Corporate firewalls can be a pain, you could well drown in a sea of red tape and meetings just to route traffic across any port but port 80 and 443. In this post we avoid swimming upstream, and go with the port 80 and 443 flow in a system level quality assurance testing scenario with a simple iptables rules.
Before we get onto the iptables rules, here is the exact scenario to give this post context.
- We have a system under test, which has a public IP address, and a remote test server which also happens to have a public IP address.
- The system under test accepts REST calls on port 443, that is we are dealing with HTTPS traffic.
- The system under test, in response to REST calls, will fire asynchronous REST callbacks to our remote test server, so we are dealing with bi-directional communication.
- A corporate firewall dictates that the asynchronous REST callbacks can only happen on port 80 or on port 443.
- Our remote test server already has a service running on port 80, so our HTTP listener, that waits for incoming REST callbacks, will have to run on another available port, say 8009.
So, here is the configuration that we will have to do on our test server.
# For a manual check of the rule below, run $sudo nc -l -v 8009 then ssh into the remote host (303.66.500.90) and execute $nc -v -z 55.333.536.4 iptables -t nat -I PREROUTING 1 -p tcp -s 303.66.500.90 --dport 80 -j REDIRECT --to-port 8009
Please note that the IP addresses where randomly generated. The rule above means that on our test server (with mentioned IP address 55.333.536.4), we’ll route traffic from our system under test (with IP address 303.66.500.90) on port 80 to port 8009. Presumably our test HTTP listener will be listening on port 8009.
Thats it, its working for me, hope it does for you too.
This post is concerned with getting Jenkins going on your public server as quickly as possible whilst keeping things private.
$ sudo apt-get install jenkins
If we have a service running on port 8080 Jenkins won’t start.
$ sudo tail /var/log/jenkins/jenkins.log
In such a case, lets change the port, and we’ll do so in the config file.
$ sudo nano /etc/default/jenkins
If this is a public server, lets add in authentication, and we’ll take the quick route by adding the following to the end of the JENKINS_ARGS (naturally change the password to suit):
The configuration up to this point is not enough when it comes to a public web server, since the world at large can still see our main Jenkins page, but its a start, since at the very least we have administrative control. We would still want to run our service over https and add http basic authentication, with the latter entailing fronting Jenkins with Apache and configuring an AJP connector between Jenkins and Apache.
If you are in rush though, or just don’t want to install and administer Apache, you can use matrix-based security to disable read privileges for anonymous users, it is easy to lock out your sole admin user if you do this though, and if you do (as I did), you’ll have to shutdown Jenkins, edit /var/lib/jenkins/config.xml and in false in <useSecurity>true</useSecurity> and start it up again. All you’ll have to do is to follow the instructions on this page for matrix-based security exactly (the sign up step seems odd, but it seems necessary). After you have signed up, disable read access for the Anonymous user and you are good to go.
/usr/share/jenkins$ sudo service jenkins stop
/usr/share/jenkins$ sudo mv jenkins.war jenkins_old.war
/usr/share/jenkins$ sudo wget http://updates.jenkins-ci.org/download/war/1.480.3/jenkins.war
/usr/share/jenkins$ service jenkins start
If all you are looking for is how to load a lazy collection with JPA, you’ll be swamped with endless posts and articles going on about the pros and cons of using lazy or eager loading. Its all noise if your question is simply how do I load my lazy collection using the JPA API?
The quick and dirty answer is just do this: singleFoo.getBars().size();
There it is. End of story. It is worth noting that I’m an advocate of using a Service Facade and DTOs, in other words clean APIs and I use Spring’s transactional annotations on the service layer. Also, you will come across posts mentioning Hibernate and initialization methods, this doesn’t help since we are only interested in pure JPA here.
Sure there is alot more to it and there are pitfalls to consider, that is old news, any layer of abstraction comes at it price and in some way dumbs you down (mmm, getting philisophical, its so easy to do).
I’ve just finished a four day Spring Core training course in Wellington, New Zealand. These are my thoughts.
I’d already been a Spring user for roughly 2 years, predominantly using 2.5.6 is a commercial setting, and had always wanted to do the Spring Core course, especially since there are areas of Spring 3 that I don’t use and don’t always get the time to work with when it comes to my day to day tasks.
What I liked about the course:
- The lecturer, who made the notes come to life. I had no idea who would be lecturing, as it turned out Spring sent a highly experienced industry veteran with a PhD in computer science, Dr. Paul Chapman.
- The student pack with notes, lab notes and preprepared SpringSource Tool Suite so we could get stuck into the labs without struggling with environment issues. Awesome.
- The labs, 30 to 45 minutes and they never cut corners, its all about best practices and Spring sticks to its guns all the way.
- The venue, with a view over the whole of Wellington.We had regular breaks with coffee and great cookies.
- The lunch vouchers and chatting to the lecturer and fellow students over lunch.
- The pace, we covered a broad spectrum of topics and roughly 12 labs. At an academic university these 4 days would have been spread over a semester.
This post is concerned with my licensing decisions regarding publishing a wsdl within a distributable jar with the view of using the Sonatype OSS Maven Repository so that I can create a demo Maven project that pulls in the jar and reference wsdl implemented by my web service (www.vouchertool.com)
I have a simple requirement, and that is to publish an artifact containing a SOAP wsdl and an accompanying set of Java classes, predominantly generated from the wsdl.
For now, I don’t want to, nor have the time to, spend hours researching the most appropriate license, all I want to do is to retain all my rights, in particular commercial rights, when it comes to my wsdl, as its my intellectual property. So, having already spent a few hours on this, including reading informative posts such as “Pick a License, Any License”, I’ve come the the conclusion that the best course of action is to pick the MS Reference License as a base and naturally I will be the Licensor, not Microsoft, and naturally there will be no platform restriction.
So, this is my way of getting my feet wet, perhaps I’m going down the wrong road, perhaps not.