I am pleased to announce that a special talk is taking place this Thursday in Carriganore at 5:30 pm in the board room.
The speaker has a wealth of legal experience from an IT perspective.
About the Speaker: Síofra Flood
Síofra has over 12 years experience with Irish software companies, formerly holding the role of Corporate Counsel at Havok, and EMEA Legal Counsel at IONA Technologies. In her current consultancy capacity, she works with companies such as Clavis, Kore, Decawave, InishTech, Headway, CloudSplit and VigiTrust; she also worked as in-house consultant for Valista during its sale to Aepona in 2009. During her career, she has been involved in three tech-company exits and numerous VC funding transactions. Síofra has a wealth of experience in the areas of software licenses, support and professional services agreements, partner & reseller agreements, employment agreements, share option schemes, due diligence assistance and commercial legal advice.
Síofra is going to give a general talk about legal matters to do with IT and software start-up companies in particular.
This will include but not limited to the following:
• Company formation
• Consulting Agreements
• Software Licensing
• Support and Maintenance Agreements
• Employment Agreements
• Intellectual Property
Síofras presentation will be followed by a questions and answers session from the attendees.
Síofra comes highly reccomended and is highly regarded across the irish software industry, I would recommend coming along and making contact as she undoubetly has first hand experience with many of the issues that you face day-to-day in the software business.
Tuesday, June 22, 2010
Friday, June 18, 2010
Pascal scripting in InnoSetup
As part of a recent project, a new standalone component was developed which was to be bundled with an existing product. One of the related tasks involved the integration of the MSI installer for the new component with the installer for the existing product, which was created using InnoSetup - a free, open-source script-driven installation system.
Piggybacking the installer for the new component was straightforward, using the following instruction in the Run section of the InnoSetup script.
Piggybacking the installer for the new component was straightforward, using the following instruction in the Run section of the InnoSetup script.
Filename: msiexec.exe;The process of uninstalling the new component along with the main product (or giving the user the opportunity to uninstall the component) was a bit more complicated. InnoSetup supports Pascal scripting for carrying out custom actions before, during, or after the install process - for example, adding custom wizard pages or installing certain files depending on runtime conditions. The script below asks the user if they want to uninstall ProductXYZ, then checks the registry for the UninstallString entry which is associated with the product code for the standalone component.
Parameters: /i {tmp}\ProductXYZSetup.msi;
StatusMsg: Installing ProductXYZ...;
Flags: postinstall
[Code]Using this method it is possible to seamlessly install and uninstall multiple related applications, without any interaction from the user.
procedure UninstallComponent();
var
ProductCode: String;
RegKey: String;
UninstallString: String;
ResultCode: Integer;
begin
ProductCode := '{1234-XXXX-1234-XXXX}';
RegKey := 'SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\' + ProductCode;
if RegQueryStringValue(HKEY_LOCAL_MACHINE, RegKey, 'UninstallString',
UninstallString) then
begin
MsgBox('Uninstalling ProductXYZ...', mbInformation, MB_OK);
Exec('>', UninstallString, '', SW_SHOW, ewNoWait, ResultCode);
end;
end;
procedure CurUninstallStepChanged(CurUninstallStep: TUninstallStep);
begin
if CurUninstallStep = usPostUninstall then begin
if MsgBox('Do you want to uninstall the Product XYZ?',
mbConfirmation, MB_YESNO) = IDYES
then
begin
UninstallComponent();
end;
end;
end;
Thursday, June 17, 2010
Replacing paper-based systems
One of the challenges in developing a system to replace paper-based processes (or part of a process) is that it is often a requirement that the structure of the original paper documents is retained. For example, data is captured digitally but must be transferred to the company's order form/invoice/etc. to complete or advance the process. In some cases, paper forms can be very complex, consisting of nested tables, multiple columns, diagram templates etc. Paper forms used by large organisations can have been in use for many years, having been designed long before digitization of information was an option, let alone a priority!
To address this challenge, Celsus Labs set out to develop a framework that could dynamically generate and populate digital forms that would mirror exactly their hard-copy equivalents. The goal was to enable an end-user to capture data on a mobile device and produce a digital document automatically, in a fraction of the time it would take to fill out a paper equivalent, and with additional benefits such as automatic data validation/processing and diagram generation. The end user could then complete the process by sending the digital document from their mobile device to a printer or fax machine, resulting in a paper form that was virtually indistinguishable in structure and content from a manually completed form (except with precise diagrams and readable fonts instead of sloppy diagrams and handwriting!).
To achieve the goal, we decided to implement functionality from the API for OpenOffice, the leading open-source office software suite for word processing, spreadsheets etc. We developed, in several iterations, a Java framework that can be used to specify mappings between pieces of data in a system to objects contained within custom OpenOffice documents. For instance, Celsus OnSite captures measurements and product design specifications, which can be mapped to OpenOffice elements so that various order forms, product specification forms etc. can be automatically produced based on the data captured by the user.
The end result of the development work was a flexible and powerful framework that could facilitate the separation of content and presentation, so that end users can concentrate on efficient data capture, while the OnSite system takes care of filling in all the forms!
To address this challenge, Celsus Labs set out to develop a framework that could dynamically generate and populate digital forms that would mirror exactly their hard-copy equivalents. The goal was to enable an end-user to capture data on a mobile device and produce a digital document automatically, in a fraction of the time it would take to fill out a paper equivalent, and with additional benefits such as automatic data validation/processing and diagram generation. The end user could then complete the process by sending the digital document from their mobile device to a printer or fax machine, resulting in a paper form that was virtually indistinguishable in structure and content from a manually completed form (except with precise diagrams and readable fonts instead of sloppy diagrams and handwriting!).
To achieve the goal, we decided to implement functionality from the API for OpenOffice, the leading open-source office software suite for word processing, spreadsheets etc. We developed, in several iterations, a Java framework that can be used to specify mappings between pieces of data in a system to objects contained within custom OpenOffice documents. For instance, Celsus OnSite captures measurements and product design specifications, which can be mapped to OpenOffice elements so that various order forms, product specification forms etc. can be automatically produced based on the data captured by the user.
The end result of the development work was a flexible and powerful framework that could facilitate the separation of content and presentation, so that end users can concentrate on efficient data capture, while the OnSite system takes care of filling in all the forms!
User Interface Design for Mobile Devices
The goal of the Celsus Onsite product was to completely replace existing paper-based systems for capturing measurements, designing and ordering products from any location. The typical existing system involved the user taking measurements at the customer's location (a building site or domestic residence for example) and writing down the values on a piece of paper along with some more information on the user. Later, the user would transfer the measurements onto an order form and draw diagrams to represent the design of the products which would fit the measurements. The challenges of replicating (and improving!) the existing systems on a mobile device with a small screen and limited input capacity resulted in several innovations in terms of user interface design.
Job Catalogue
The core of the Onsite user interface is a multi-level tree structure which displays all the Builders, Estates, and Houses in the user's job catalogue. Each time the system is launched, new items that have been created by the administration system are automatically added to the tree. New items can be created quickly and easily on the mobile device and are automatically synchronized with the central database. With the paper-based system, a user's job history is typically split over multiple order books and there may not be any conventions or processes for storing measurements taken at job sites for validation purposes. The OnSite system allows the user to browse or search through their entire job history quickly and easily, using a very simple and intuitive interface.
Measurement Capture
The measurement capture screen of the OnSite system had to enable the user to record a lot of information while minimising the need for manual input on the device. During this task, the user can survey an entire building with most of the actions being driven by an external measuring device which interacts with the system over a Bluetooth connection. Because the user is often using both hands to operate the measuring device, it is beneficial to have as little interaction with the OnSite device as possible. The only interactions required from the user are the selection of the side and level of the building being surveyed, and the particular type of item being measured, if it is a non-standard design. Each time a measurement is received by the system, the data is validated, and the next data-entry field is highlighted. The user receives audio feedback that indicates whether or not the data has been accepted, meaning that the user's main focus can stay directed on the measuring device and the item being measured. Once a building has been surveyed, the user can easily review and amend all the data that has been captured. The measurement capture screen displays to the user, at a glance, the side and level of a building they are surveying, the number of items on that particular side and level, the status and various properties of the item being measured, and the validity of the values being recored on the measureing device. The interface also allows the user to edit this information quickly and easily, put prevents accidental interaction and the entry of invalid data.
Product Design
Another challenging area in terms of UI design was the product configuration and design process. The process of designing windows, doors etc. on a desktop environment would usually involve multiple diagrams, pop-up dialogs, menus, toolboxes etc. but in the OnSite system for mobile devices where screen space is limited, a product can be specified in a simple step by step wizard interface. Standard items can be designed quickly and efficiently, while more complex items can be created based on product templates which are centrally managed and distributed to each of the mobile devices on a continuous basis. Items that are designed on the device can be saved as templates for future use, speeding up the process and greatly reducing repetition of input. The user receives constant and clear feedback to ensure that products being specified meet with validation criteria throughout the design process.
The design of the interfaces above involved many, many scribble-filled whiteboards and lots of head scratching, but all the hard work is validated by the positive experiences of the OnSite users!
Job Catalogue
The core of the Onsite user interface is a multi-level tree structure which displays all the Builders, Estates, and Houses in the user's job catalogue. Each time the system is launched, new items that have been created by the administration system are automatically added to the tree. New items can be created quickly and easily on the mobile device and are automatically synchronized with the central database. With the paper-based system, a user's job history is typically split over multiple order books and there may not be any conventions or processes for storing measurements taken at job sites for validation purposes. The OnSite system allows the user to browse or search through their entire job history quickly and easily, using a very simple and intuitive interface.
Measurement Capture
The measurement capture screen of the OnSite system had to enable the user to record a lot of information while minimising the need for manual input on the device. During this task, the user can survey an entire building with most of the actions being driven by an external measuring device which interacts with the system over a Bluetooth connection. Because the user is often using both hands to operate the measuring device, it is beneficial to have as little interaction with the OnSite device as possible. The only interactions required from the user are the selection of the side and level of the building being surveyed, and the particular type of item being measured, if it is a non-standard design. Each time a measurement is received by the system, the data is validated, and the next data-entry field is highlighted. The user receives audio feedback that indicates whether or not the data has been accepted, meaning that the user's main focus can stay directed on the measuring device and the item being measured. Once a building has been surveyed, the user can easily review and amend all the data that has been captured. The measurement capture screen displays to the user, at a glance, the side and level of a building they are surveying, the number of items on that particular side and level, the status and various properties of the item being measured, and the validity of the values being recored on the measureing device. The interface also allows the user to edit this information quickly and easily, put prevents accidental interaction and the entry of invalid data.
Product Design
Another challenging area in terms of UI design was the product configuration and design process. The process of designing windows, doors etc. on a desktop environment would usually involve multiple diagrams, pop-up dialogs, menus, toolboxes etc. but in the OnSite system for mobile devices where screen space is limited, a product can be specified in a simple step by step wizard interface. Standard items can be designed quickly and efficiently, while more complex items can be created based on product templates which are centrally managed and distributed to each of the mobile devices on a continuous basis. Items that are designed on the device can be saved as templates for future use, speeding up the process and greatly reducing repetition of input. The user receives constant and clear feedback to ensure that products being specified meet with validation criteria throughout the design process.
The design of the interfaces above involved many, many scribble-filled whiteboards and lots of head scratching, but all the hard work is validated by the positive experiences of the OnSite users!
Distributed Version Control
Like many other software houses, we in Celsus Labs are very aware of the advantages of distributed version control and have been toying with the idea of moving our entire code repository to a distributed system. The typical result of any discussions on the topic is something like "Yeah, sounds good, let's do it! Eventually!". Any procrastination arising from this is the thought of having to port all our existing code from Subversion, but even a small amount of research on the task has us running out of excuses pretty quickly...
Mercurial? Git? Bazaar? The debate rages on... With over a million search results for 'X versus Y', there is no shortage of opinions and case studies on the topic, and it goes without saying that there is no obvious choice that suits every user and every situation.
Some factors in our decision are level of functionality, ease of use, branching and merging behaviour, and support for migration from SVN. Although we are no strangers to the command line, scripting etc., the convenience of GUI clients (TortoiseHg for example) and IDE integration also has some weight in the decision.
Recently, some of the team started using Subversion and Mercurial in parallel - Hg for versioning local changes, which are then committed to a central SVN repository. It seems we have already stared down the road towards a complete migration to distributed version control...
Thoughts...?
Some links:
Hg Init: a Mercurial tutorial by Joel Spolsky
Mercurial ConvertExtension
TortoiseHg
A collaborative Git guide on stackoverflow
Pro Git Book
Mercurial? Git? Bazaar? The debate rages on... With over a million search results for 'X versus Y', there is no shortage of opinions and case studies on the topic, and it goes without saying that there is no obvious choice that suits every user and every situation.
Some factors in our decision are level of functionality, ease of use, branching and merging behaviour, and support for migration from SVN. Although we are no strangers to the command line, scripting etc., the convenience of GUI clients (TortoiseHg for example) and IDE integration also has some weight in the decision.
Recently, some of the team started using Subversion and Mercurial in parallel - Hg for versioning local changes, which are then committed to a central SVN repository. It seems we have already stared down the road towards a complete migration to distributed version control...
Thoughts...?
Some links:
Hg Init: a Mercurial tutorial by Joel Spolsky
Mercurial ConvertExtension
TortoiseHg
A collaborative Git guide on stackoverflow
Pro Git Book
Wednesday, June 16, 2010
Using SQL Lite with MSSQL backend
Hello there,
During early R&D on our mobile data collection product written for windows mobile we came up against the issues of the un-reliability of MSSQL for Win CE, so we decided to look at alternative options.
The key areas which we stumbled on with MSSQL for Win CE were:
1. Poor Database Performance
2. Corruption of Data due to power failure on device
3. Poor replication on MSSQL for Win CE with backend databases
4. Bloating of Mobile Database
We found a super alternative which is SQL Lite!
Much faster, much much faster in fact its lightening fast
Extremly fault tolerant
In terms of replication .. well we wrote our own replication engine .. more on that later
Very small foot print
We hand coded our replication using SOAP filled with data objects, and we built a http compression engine to optimize comms with the backend.
Following on from this we built synchronisation engine, where we could do a number of things.
1. Backup entire database to MSSQL backend
2. Incremental backup of database to MSSQL backend
3. Built some a data synch engine with simple workflow allowing jobs to be pushed out to mobile users from a PC client, fulfillment of jobs on the mobile client and final synchronisation back to complete workflow.
During early R&D on our mobile data collection product written for windows mobile we came up against the issues of the un-reliability of MSSQL for Win CE, so we decided to look at alternative options.
The key areas which we stumbled on with MSSQL for Win CE were:
1. Poor Database Performance
2. Corruption of Data due to power failure on device
3. Poor replication on MSSQL for Win CE with backend databases
4. Bloating of Mobile Database
We found a super alternative which is SQL Lite!
Much faster, much much faster in fact its lightening fast
Extremly fault tolerant
In terms of replication .. well we wrote our own replication engine .. more on that later
Very small foot print
We hand coded our replication using SOAP filled with data objects, and we built a http compression engine to optimize comms with the backend.
Following on from this we built synchronisation engine, where we could do a number of things.
1. Backup entire database to MSSQL backend
2. Incremental backup of database to MSSQL backend
3. Built some a data synch engine with simple workflow allowing jobs to be pushed out to mobile users from a PC client, fulfillment of jobs on the mobile client and final synchronisation back to complete workflow.
Publish Post
Auto Update of Mobile Apps
Hello there,
A product which we developed called onsite, is a mobile application for windows mobile. It is used primarily by field workers for large engineering companies, allowing them to remotely order products while out on the road over mobile networks.
A challenge which we faced during startup was how do you easily update 100's of mobile users without having to physically update each of their devices?
Something which compounded this problem a little more, infact probably led us to development an elegant solution was the fact that the mobile users did not have any knowledge of software, and did not have PC's to connect for messy manual updated.
The solution was to build a client update systems, which would automatically check our online upgrade system on startup each time the application started.
Application Updates
The update system has a number of options for app updates.
1. Enforcing updates (the end user cannot start their application until it has been updated)
1.1 The problem of enforcing updates was further compounded by the fact of "how do you enforce updates if the user has already connected / is already using their app". Time to add another layer... As with most mobile apps, ours has a big online aspect and comms over web services are where you can orchestrate more control over users.
We decided to allow for in-app enforcement of updates, simply adding update checks during the normal course of comms with our backend.
1. User Driven updates (the end user has the choice to update if they like)
Data Updates
Further to the above also you have the issue of data updates, our application sits on a mobile SQL lite database (lightening fast, very fault tolerant, as good as anything out there) , and it is very reasonable to imagine that if updating an application, also you may have to update a database.
So next to updating the database; we implemented a database version control system as part of our update server where on checking for updates the mobile application could download and run any SQL scripts necessary to bring the mobile app up to the latest version.
Deployment of 1 app :-)
One very nice thing that fell out of the update application was that in terms of deployment, our original installer (now 4 years old) can still be run on a mobile device, and on startup the application and database will be automatically updated to the latest and greatest version.
Mobile administration for mobile enterprise!
A product which we developed called onsite, is a mobile application for windows mobile. It is used primarily by field workers for large engineering companies, allowing them to remotely order products while out on the road over mobile networks.
A challenge which we faced during startup was how do you easily update 100's of mobile users without having to physically update each of their devices?
Something which compounded this problem a little more, infact probably led us to development an elegant solution was the fact that the mobile users did not have any knowledge of software, and did not have PC's to connect for messy manual updated.
The solution was to build a client update systems, which would automatically check our online upgrade system on startup each time the application started.
Application Updates
The update system has a number of options for app updates.
1. Enforcing updates (the end user cannot start their application until it has been updated)
1.1 The problem of enforcing updates was further compounded by the fact of "how do you enforce updates if the user has already connected / is already using their app". Time to add another layer... As with most mobile apps, ours has a big online aspect and comms over web services are where you can orchestrate more control over users.
We decided to allow for in-app enforcement of updates, simply adding update checks during the normal course of comms with our backend.
1. User Driven updates (the end user has the choice to update if they like)
Data Updates
Further to the above also you have the issue of data updates, our application sits on a mobile SQL lite database (lightening fast, very fault tolerant, as good as anything out there) , and it is very reasonable to imagine that if updating an application, also you may have to update a database.
So next to updating the database; we implemented a database version control system as part of our update server where on checking for updates the mobile application could download and run any SQL scripts necessary to bring the mobile app up to the latest version.
Deployment of 1 app :-)
One very nice thing that fell out of the update application was that in terms of deployment, our original installer (now 4 years old) can still be run on a mobile device, and on startup the application and database will be automatically updated to the latest and greatest version.
Mobile administration for mobile enterprise!
Porting legacy Fortran Code
Recently we worked on a project where we had the task of repackaging some legacy fortran code for use in a .net environment.
The key driver behind this task was to retain the original source code and logic as it has been rigorously tested and used over the years.
The challenge here was to put a new frontend with graphics onto the original code base and also to pave the way for the addition of new features to the original code base.
The key driver behind this task was to retain the original source code and logic as it has been rigorously tested and used over the years.
The challenge here was to put a new frontend with graphics onto the original code base and also to pave the way for the addition of new features to the original code base.
Subscribe to:
Posts (Atom)