Blog1 2 3 4 5 6 7 8 9 10 ← Newer Older →
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 ;)
How Smartcards Work 7 November 2014, by Ste
Smart cards with ITSO are very powerful. The technology can come on a plethora of cards, and store all sorts of things from cash value, to loyalty points, to travel passes. I'd like to explain a little bit about how that data gets there, and how we use it.
First off, ITSO is two things: A technology for making an interoperable smart card environment, and the organisation which makes it happen, by developing standards for cards, readers, and software. ITSO (that is, the "Integrated Transport Smartcard Organisation") pick and mix a number of international standards for how smart cards interact, and oversee the process of making the parts work together, with the help of a number of transport companies and local authorities. ITSO is not-for-profit.
The point is that all ITSO smart cards are theoretically compatible with all ITSO entry gates, top-up points, etc. (ever noticed the train station ticket barriers which say "ITSO / Tickets" on the screen?) However, in practice, not all travel cards are meant to work with all services! You can't use your Oyster card on Merseyrail, but at a secret level, the technology can work together.
Smart cards are known as Customer Media (CM) and contain one or more applications. Apps on a smart card are not like applications you're used to! In fact the combination of apps which make up the "ITSO Shell" have the charming names: 00, 16, 02, and A0, and they deal with data which is about as readable as their names.
The applications contain products, known as IPEs. The IPE could represent monetary value, and have its value changed whenever the customer tops up or passes through a payment gate. Or it could contain a pass representing a month of travel, which the pedestal on the bus can verify and allow the customer aboard. These are encrypted very strongly using a special server so that you can't hack your own card to get free travel!
The commands we send to the card are known as "Application Protocol Data Units" (known as "APDUs", pronounced "App-doos" which is funny in my opinion because you use them to ask an App to Do something! It's a wonderful world.)
We compose these APDUs ourselves for lower functions such as simple queries of card data, but for the complex (and encrypted) business of loading and unloading products, we rely on a Part 11 service, which I'll discuss in a future post.
This primer should serve to demonstrate how complex and yet familiar the ITSO system is. We are experts in this area, as well as in the hardware necessary for smart card operations, and we're an agile team, able to keep up nimbly with specifications and project demands. There's basically not a better squad in the country for creating a new smart card solution, and if that sounds about right for your scenario, get in touch with us; we're email@example.com.
Umbraco Friday 31 October 2014, by Ste
As .Net developers, we're ideally set-up to make smart websites with some of the best technology around. Umbraco is a flexible content management system which lets us write C# code to make dynamic websites, and we use it in a growing number of projects:
As well as running this and our LabCom site in Umbraco, we currently work with it for three of our clients, so it's definitely a growing capability. We have all the knowledge within Village to run it from a VPS in a traditional host, or Microsoft Azure, or to run the whole thing in a Microsoft Azure Website instance (the advantages of Azure include scalability and economy of scale, but that's for another blog post!)
The cool thing for me as an Umbraco developer is that I start each website like a blank slate. Whereas in Wordpress you begin with defined objects like pages and comments, Umbraco gives me the ability to design every type of object and how it will display to the website admins who will use the CMS. This lets me make a really user-friendly structure with fields which are tailored to the type of information which your website displays! So rather than a one-size-fits-all approach to page management, I can design your staff page so that you add "People" with attributes like Name, Bio, and Email.
These tailored elements are displayed to the user with clever so-called "macros", custom-written by us in C#. Plus, being able to use all of the power of ASP.Net MVC from within Umbraco gives us major flexibility to write full web applications within your website! Or, for example, to create "partial views" which let visitors navigate information without leaving the page, using AJAX technology. This can create a really smooth and delightful user experience.
If your website features a complex bespoke system, then graphic-design-centric web development houses may lack the enterprise chops needed to understand, maintain, or rebuild that system.
- New web projects, with or without CMS
- Umbraco website maintenance
- Moving existing websites (in another system) to ASP.Net/Umbraco
...and we have indeed undertaken all of the above for our other clients!
If you need heavyweight application developers with a great mix of web abilities, you probably need Village Software. To talk about any kind of web project, please just email us! We're firstname.lastname@example.org
Contactless Smart Cards 27 October 2014, by Michael
These cards, similar to recently introduced contactless payment cards, allow for a simplified transaction process whilst providing a richer experience for the end customer.
We have been dealing with one of the most common types of smart card on the market, the MIFARE DESFire. The DESFire is a hard plastic card with an internal chip that can store a variety of data, and is most commonly used to store products that a customer can expend e.g. travel passes. In this particular instance, Village has been utilising ITSO part 11 services to add travel rights and passes onto smart cards for use on a variety of public transport throughout the UK.
In order to store values on a DESFire, it is necessary to learn the surrounding smart card technology and associated protocols. Application Protocol Data Units (APDUs for short), are small packets of information that are sent to the card in order to instruct it to perform read/write operations as necessary. To communicate with the smart card we must construct and send APDU packets. The smart card then returns reponse data in the form of APDU response bytes, which are then parsed and handled as necessary. The response packets are interrogated carefully as they contain status codes which indicate whether there is more data to read from the card, allowing us to continue or terminate execution as necessary. This requires a level of understanding that can only be gained through lots of exploration in to how the technology works - something which Village has invested the time in and has become more proficient over the past 12 months. Addtionally, as each part 11 service operates in a slightly different manner, we have the experience of integrating with a number of different environments whilst still providing the same level of functionality.
In order communicate with the contactless smart cards, you need to use hardware that is capable of doing the job. Village has first-hand experience of communicating via several MIFARE-ready readers including the ViVOPay Kiosk II, Newbury Data Printer ND4030 and (primarily for developmental purposes) the Omnikey 5321.
One of the more challenging aspects of using these card readers is managing the way we communicate to them. Each device exposes a different physical interface (e.g. serial port or USB), and in most cases require device-specific commands in order to access the deeper functionality of the readers. This complexity requires a deeper understanding of the hardware and the careful management of bits and bytes to ensure data is correctly transmitted to and from the card. When you combine these device-specific requirements + the understanding of ITSO + the utilisation of APDUs and their responses, it is apparent that Village has a considerable amount of knowledge in the area.
If you'd like to make use of said expertise, please get in touch! We're email@example.com
Pot Noodle Engineering 23 October 2014, by Michael
As a part of our growing kiosk capabilities, we have been integrating with more and more hardware to help develop a fuller solution. In addition to the payment devices that were discussed in a previous blog post, we have been integrating with a receipt printer called the Zebra TTP 2030.
Receipt printers provide one of the key requirements of a transactional kiosk - the ability to issue receipts. These small pieces of thermal-coated paper provide proof of purchase, or in some cases proof of voided transactions when things don't quite go to plan.
There are hundreds of receipt printers available on the market, but we have been working with a client who requested the use of the Zebra model. We found that implementing the TTP2030 was, for the most part, relatively straight forward and required very little configuration. However, you must learn ZPL (Zebra Programming Language) to harness the full capability.
The Zebra Printer (formerly manufactured by Swecoin), presents itself automatically as a printer within the Microsoft Windows operating system. You can download specific drivers from the Zebra website, which in turn allow you to control more advanced functionality such as fine adjustment of cut lengths etc. The standard print management available in Windows offers far less adjustment, but for our solution we opted to use this as it offers the capability to use it as a standard printer via the .NET Framework. This restricts the ability to send it raw ZPL, meaning we had to create our own receipt template markup to generate nicely-formatted receipts.
In addition to printing text on paper, we also need to interrogate the printer's status at set intervals for maintenance monitoring. As the device is a part of a kiosk solution, the health of the system needs to remotely monitored to ensure all of the vitals are in check. A receipt printer such as the Zebra TTP2030 isn't like your standard laserjet/injet, so it uses different status codes to report device-specific information. For example, thermal receipt printers do not use ink, therefore the ink-low status reported by the Windows printer driver doesn't correlate to the actual status being reported by the Zebra. For this purpose we had to create a mapping between the reported statuses and translate them into the true statuses from the TTP2030.
Finally, you may be wondering about the relevancy of the title - what do Pot Noodles have in common with receipt printers? It turns out that two used pots, combined with a pen, provide the cheapest and quickest receipt roll holder. Despite being extremely portable and secure when celotaped to a desk, I don't think they'll be available on the market any time soon. Let's stick to writing software!
Working with Spire and Ingenico 22 October 2014, by Johnny and Lee
One of our team's most recent pieces of work has been integrating payment devices into kiosk solutions for a client.
The business of taking a payment from a card and pin involves a web of different providers extending out from the banking system. Our role is to pick up the transaction and integrate it with a business process. This involves our business workflows interacting with a payment device as a device goes through a process of:-
- Verify the Card
- Verify pin
- Commit transaction and verify funds with the primary acquirer
The primary acquirer is the next layer into the banking system managing the transaction.
We have been working with two self service payment devices; the Spire Modular and the Ingenico's iSelf IUP250. We created software wrappers for both of these physical devices, exposing their core functionality to our clients' business workflows. We have integrated both devices (as different end users have relationships with the different equipment suppliers and their partners) and our solution makes the devices interchangeable. Below, Lee, who worked on this, outlines some of the issues.
Integrating with SPIRE
With the Spire device we receive access to a 'static C library'; a programming interface we can address using unmanaged code. However as a business software developer we normally choose to work in managed code -- this means that our developers spend their time thinking about the business rules we are building into the software, and not internal computer memory structure, allocation, etc.
So, we needed to create a wrapper around the Spire library that allowed it to be integrated with managed code on a Windows system. We tackled this by writing some unmanaged C++ code and pulling it into a wrapper that managed code could read. From there, we could pull the functionality into our normal development environment. There were a few tricky 'gotchas' on the way; capturing events such as payment failures, and allowing the software to decide how to respond.
Integrating with Ingenico
For working with the Ingenico devices we started somewhat further down the path: for the relevant 'Primary acquirer' (Credit Call) the device came with a managed code library we could work with. If this was not the case it would be a matter of rolling up our sleeves and tooling up to programme on Ingenico’s Telium platform. The developers would love to do this, however there has to be a pressing need for such expense.
Getting Help Pulling it Together
Key to pulling all of the elements together, in a standard platform, alongside smartcard and other elements of the final solution, is having someone to talk to. When needed, we have been able to get on the phone for a bit of support for our development process. Hemisphere West, who were the supplier of the equipment, were helpfully able to answer or signpost us to the right source of information. We also spent some time on the phone to Credit Call for the Ingenico interface, and Spire for building the wrapper around their system. It takes a string of relationships to pull these systems together and some project management persistence.
We Can Do It
If you're interested in applying Village Software's expertise and tenacity to your business situation, then drop us a line! We're firstname.lastname@example.org
1 2 3 4 5 6 7 8 9 10 ← Newer Older →