Blog1 2 3 4 5 6 7 8 9 10 ← Newer Older →
Why Azure? 26 June 2015, by Ste
Microsoft Azure is a service we use to host websites, web services, and databases, powered by Microsoft's datacentres around the world.
Azure supports a dazzling array of different computing features. A lot of people presume that it's like a traditional Virtual Private Server, where you start up a Windows or Linux Virtual Machine and run any applications you need to on there. That's called IaaS (Infrastructure as a Service), and while Azure does support many such options, they're not the best thing it has to offer.
What if you could receive the pure benefits of running web apps and databases without ever having to think about the underlying operating system, scheduled maintenance, and updates that go with it? Well, that's exactly what Azure offers with "Platform as a Service" (PaaS) functions! In minutes, we can start up hosting for:
- Web apps and APIs;
- MS-SQL or MySQL databases;
- Even 'Machine Learning' and massive 'Search as a Service' instances!
Microsoft manage all of the underlying tech, so the Windows Servers that your sites run on are always secure and up-to-date. As you'd expect from the cloud, all of these solutions can be made scalable and georedundant.
And, amazingly, these services come cheaper than a self-managed VM!
We are experienced in hosting massive sites and APIs on the Microsoft cloud. Make us your trusted partner for delivering future-thinking solutions like these! We are email@example.com
Jenkins - Getting Your House in Order 22 May 2015, by Ste
It's great to be able to release your code in a solid, reliable way.
Let me illuminate that for you a little:... imagine if one developer normally works on some project, called "DataThing". The developer knows exactly how to build and release DataThing, of course. "I set the mode to Release, click Rebuild and Deploy All, then connect over USB to the remote device it deployed to, copy the program files into a zip..." uh-oh.
They might document that process really well, but something is still wrong here, and could just be better.
That's why enterprise-grade software houses, like Village, use Continuous Integration tools like Jenkins. Jenkins runs on one of our office servers. Everytime someone checks their code in, Jenkins takes a copy, builds it in a predictable, configurable way, and can then (if we want him to) release the software to a remote server.
We have 22 different projects which are managed by Jenkins!
This is great!... But it also makes it a bit tricky if, one day, we want to move our Jenkins installation onto a new server. Well, that day is coming, and since our Jenkins home directory (where he keeps builds of all the different projects) is a whopping 55GB, I thought it might be time to get our house in order. We were so busy writing software, we didn't realise that the CI server had taken such a big slice of our hard disk space!
Giving the butler a broom
A spot-on feature in Jenkins for avoiding this kind of thing is "Discard old builds". Turn this on for a project and configure a number of days, and Jenkins will only keep versions built in that last period of time. Simple.
A question to which I couldn't find the answer online was "When does Jenkins discard old builds?" as I had configured the option but nothing was purging. It turns out that it does so upon the next build.
This is good because I wanted to mark some as "Keep forever" first, and you can only do that once the discard option is turned on! So I picked some choice milestones to keep safe with the "Keep forever" option, and then triggered a build manually for the projects I wanted to tidy up. Note that the last successful build and last stable build are always kept forever, so you don't need to mark those.
Next, we have a couple of really old projects which have been on the backburner for two years or more. These were set to build on a regular schedule, cluttering up the system. As such, I simply used the "Disable build" option for them. When we come back to them, it's one click to re-enable and get going again!
Using Jenkins is just a part of our solid practice as a software development company. The good news is that you can leverage this brilliance for yourself. If it sounds good to you, get in touch with us, firstname.lastname@example.org
And if not, hey, I hope this article helps you out! Have a successful week.
Engineering the ViVOPay reader 30 March 2015, by Ste
Do you ever fly through the M6 Toll gate with your contactless payment card and think, "What was that charming little card reader back there that made this all so easy"? ... No? Maybe it's just us then. Either way, that's how Village Software first discovered the ViVOpay Kiosk II. It's a powerful little device, capable of taking payments as well as gritty data transmission with all sorts of customer media. From the user guide:
"The ViVOpay Kiosk II is a compact stand-alone contactless reader designed to support contactless transactions based on ISO 14443 Type A/Type B/MiFare compatible cards, fobs and tags as well as NFC phones."
The ViVO has become a critical component in a whole host of our TVM (Ticket Vending Machine) and Kiosk solutions. We engineered our own tools to communicate using the device's particular protocol, and now we can make it do anything. Currently, we use it to read and update customer media (smart cards) and are working on using it to take payments too. Plus it lights up and beeps. That's a personal favourite.
We can integrate our ViVOpay code into practically any line of business situation, but it has a clear calling to the world of ITSO. The ViVOpay reader is a tremendous fit for collection, validation, fulfilment and retail. It's fast, it's reliable, and we can even hook it up to Windows CE to run on limited hardware.
When it comes to this device, we've been there, done that, and actually, I'm still finalising the T-shirt design. But if you need a team who have experience with its protocol and capabilities, you could probably save yourself a lot of time by getting in touch. We're email@example.com. Tap in!
Kiosk Printer Language (KPL) 9 January 2015, by Ste
Zebra brand printers are an industry standard in thermal printing, and they work great in our smart card kiosk projects. But there is one mystery of these systems... so-called 'KPL' or 'Kiosk Printer Lanugage'.
The Zebra website says this on one of its driver download pages:
"Software that will enable you to send an ASCII string [...] can be used if that ASCII data is in the form of the printer's native command language. Depending on the model of the printer this will be Zebra Printer Language (ZPL), Eltron Printer Language (EPL), Comtec Printer Control Language (CPCL), or Kiosk Printer Language (KPL)."
Now, there is a good deal of documentation for ZPL and EPL. You can find questions on Stack Overflow from people trying to implement them. But their little brother is the peculiar one, appearing mainly in Zebra's Toolbox software. As far as we can tell, Toolbox is the only readily available piece of software in the world which can send these KPL codes to your printer in a way which it can understand!
This is important because, as the quote suggests, sometimes you need KPL in order to use features of your printer such as Barcode and QR code generation, or advanced paper feeding/cutting commands.
Well, Village Software can now proudly proclaim that we have our very own module for parsing and sending KPL commands to print. Our very own Dom has put some time into a clever little piece of programming which translates the commands into the binary format required by the device. In fact, here is a little barcode proof-of-concept which Dom's program sent to our Zebra TTP 2130.
So, if you're looking for a software company which can wrangle your Zebras (or other compatible printer!) into printing KPL commands from within your application, look no further! We're firstname.lastname@example.org if you want to have a chat.
All Part and Parcel 15 December 2014, by Ste
Today, I'd like to go into more detail about the courier data services used within our eCommerce parcel packing product; we can apply these industry standard capabilities to almost any new or existing product.
At Village, we maintain and expand a piece of software for packing and labelling eCommerce orders. I've mentioned it before in my post Shipping Evolution. All of the services built into it perform roughly perform the same function: They allow the courier to create their own database record for the given order and delivery information, and they provide us with confirmation, tracking numbers, or label data to affix to the parcel.
Royal Mail DMO (Despatch Manager Online)
Royal Mail's DMO software would run on a server within your warehouse, and constantly monitors a directory for input files which contain shipping information. We have used a network share for this folder, so that four packer PCs can use DMO at once. As it processes the input files, it prints a barcoded label, and creates an output file in a separate directory, comprising a status code and error description (if necessary).
We have modules of code designed to communicate with the DMO server, plus experience of setting DMO up on the network, and connecting it to the network printer. We can do these things using remote access without need of client site access, so response times are comparably short.
You can read more about DMO on Royal Mail's website.
Xtend is CityLink's very similar rival application to DMO. It follows the same pattern of use, and can have multiple configured network printers. It also prints labels, and its output file produces a tracking number which you can pass on to the customer.
Likewise, we have plenty of experience configuring Xtend, as well as a comprehensive module of code to talk to it.
Hermes MOD API (Method of Delivery)
Hermes is different to the other carriers above, as it uses a web service for label production. This was by far the most technically challenging option to develop and debug, as there is very thin documentation for the service, which doesn't even mention the major "gotchas" which lengthen development time. To write a component from scratch which does the same work as our Hermes Label API component would be a very time consuming and error-prone process.
The Hermes MOD API uses packets of XML to communicate consignment information, at which point the courier creates the relevant records at their end, and assigns a Method of Delivery to your despatch (hence the name). The service will then provide label data upon request. We can create deliveries, collections, and returns using this method, with either domestic or international destinations.
Our Hermes Label code handles all of the authentication and back-and-forth needed to authorise shipping and create labels with this popular courier.
As you can see, we have the experience and the code property you need to get your business up and running with a choice of couriers in minimal time. That's because we're email@example.com, and that's just where you can send your email with further enquiries.
That Christmas Feeling 11 December 2014, by Ste
Today was a lovely day at the office, rife with Christmas cheer and busily typing fingers...
Johnny and I put up the Christmas decorations first of all, and our friend Nisreen who is currently doing work experience with us cooked a lovely spread of chicken, spicy rice and roast almonds for lunch. To see the whole team not only in the office, but congregated to eat together is quite a rare find!
Between that and Kat's generous tribute of a tub of Quality Street, it suddenly started to feel rather festive in the Village office! We are working on a surprising variety of things today - a quick look in the timesheet report shows website redevelopment, documentation and data archiving for an eCommerce site, support for our LabCom users, setting up the development environment for a different eCommerce project, integrating a new cash reader into a kiosk project, and hashing out the final specification for another kiosk project... whoof, we're busy bees.
There's an ideal mix within Village of specialisation and general project knowledge, if you ask me. It means that there are always capable hands around to work on any given project, and the ability to take on close to anything. If you're wondering who can work on your new/old big/small software system, it's probably us. So, to get in touch for a chat; we're firstname.lastname@example.org. And if you end up in the office, maybe we'll even let you have a sneaky dip in the Quality Street tin ;)
1 2 3 4 5 6 7 8 9 10 ← Newer Older →