More on syntax checking vala - and a nice video

As I wrote last week. I had added full syntax checking to the editor. So it runs a full compile check as you type.
Here's a nice video of it working...

After the initial joy of adding this to code, I soon realized it had a fatal flaw, read on to find out more..

Posted by in at 2015-05-20 00:00:00 | Add / View Comments()

Fetching Resources from github in the App Builder and fake web servers

My final words this week on the builder - handling resources, and fake web servers

While I talked in the other posts about how the builder extracts the API for various components from the libvala library and the vapi files, some information that the builder requires has to be manually, created or fetched from other locations.

When the Builder was written in seed, it basically looked at the source code directory, and read files relative to the source code. For the Vala version however, it's not expected to know about the source code directory, so I had to use a different approach.

Posted by in at 2015-05-09 00:00:00 | Add / View Comments()

libvala testing code and extracting API from the vapis

And the next part in the series. Gir and Vala structures, Nothing like a slow day to write a few blog posts. 

The App Builder was originally designed to build applications using seed (the gobject introspection webkit javascript engines bindings), One of the key elements of how this was done involved introspecting the Gtk API, and extracting all the properties, signals and class structure.

In this post I will go through the history of how I extracted the API information on Gtk, initially from Gobject introspection and GIR files, upto the current version which uses libvala to get the correct API direct from the vapi files.


Posted by in at 2015-05-08 00:00:00 | Add / View Comments()

App Builder - Database based Plugin builders for Web components.

It's been a busy month, unfortunately not for our paid work, which has dropped down to a trickle. Taking advantage of this I've been building more into our App Builder. This post hopefully is the first in a series about some of those additions.
The Primary purposes of our Builder is
  • A WYSIWYG tool for web applications using both Bootstrap or the RooJS libraries.
  • A new visual way of building Gnome/Gtk Applications 
In working towards these goals the builder has moved forward in a few directions. the first one that this blog post talks about is generating User interfaces from Database Schemas.

Posted by in at 2015-05-07 00:00:00 | Add / View Comments()

App Builder - Vala

As we are not so crazy busy this month, I finally get time to write about one the  key tools that we developed to enhance our development process.

Back in 2010, We built a desktop application called app.Builder.js, written in seed (webkit+gnome). It's main purpose was to enable the rapid development of RooJS applications (a fork of ExtJS). It worked wonders over the years, enabling us to build and prototype applications quickly, and continually improve on them.

While it worked well, due to the nature of Javascript bindings into C, the occasional code problem would cause a complete crash. As most of the code is dependant on the javascript bindings, and gir files that define them. It also became a little troublesome to maintain, extend as it was dependent on the availability of gir bindings for new widgets.

Around mid 2014, It was decided to port the code from Javascript to Vala. Being a relative new-commer to Vala, we first tried porting our Gitlive application, which monitors the filesystem for changes and instantly commit's and pushes all changes. This relatively small project gave us the skills set ready to rebuild application builder in vala.

Posted by in at 2015-03-17 00:00:00 | Add / View Comments()

The Roo Bootstrap library.

A little update on our latest little mini project. Wrapping the Twitter Bootstrap library into RooJS Objects, and creating a manageable method to develop Bootstrap applications without the JQuery spaghetti. 

Posted by in at 2014-05-12 00:00:00 | Add / View Comments()

FIFO on xtuple


It can't be that difficult can it?......

Background


As part of our implementation for Xtuple, one of the key requirements was to value the stock using FIFO rather than the methods offered by default in Xtuple. After migrating from Netsuite, this became the next major task in our implementation. It took almost a year to develop, initially the first release took around 5 months, but it was only after many rounds of fixes and tweaks that we finally got to a situation where it would correctly calculate the stock valuation and correctly apply this to the General Ledger.

Posted by in at 2013-07-30 00:00:00 | Add / View Comments()

PHP just does some things better. cloud backups, pecl-expect

 Backups, yes we do backup occasionally, and I've been looking for a better solutions than my historical office<->hosting replication, which although cheap, always made me wonder if I was still making copies. So after our recent office move, and minor server upgrade, I thought better double check on it all.. As usual, the thing had failed due to various reasons, and needed replacing. 

So since I've been thinking about a new solution for our clients, I decided to go ahead and try it out for our data. I've been googling affordable cloud based storage for a while and found a company onlinestoragesolutions.com, the pricing is very reasonable US$45 for 2 years currently, with unlimited everything. There are a few review sites that seem to throw some cold water over the offer, but I had one client sign up without any major issues (for another reason), so at that price I though let's give it a go....

One of the key features they advertise is rsync, which since we run all linux machines would be ideal. However after paying, and getting access, I realized it's not quite a simple as pointing your rsync at their server. You need to set up an ssh tunnel to route rsync through.

Can't be that difficult I thought.... Turns out that setting up a password based ssh tunnel, automatically on a cron job, is no small task, there are questions all over stackexchange and various forums, none that I saw managed to find a solution. Most of the suggestions are based around the 'expect' program, a usefull unix tool which can be used to script ssh access. The problem in this case was that setting up the tunnel, then doing the rsync, and then closing the tunnel is not something that a bash, expect or any other method I found could do easily if at all.

So almost at the point of giving up, I started looking around at php's popen (which would not work either), and fell over the pecl expect extension. 

Below is the result of a few minutes coding, which does exactly what is needed, and can be run directly from cron. Feel free to escape from overpriced backup solutions..


Posted by in at 2013-03-04 00:00:00 | Add / View Comments()

Roo J Solutions Growing into 2013, always recruiting, and developing differently

As the business is always growing, finding time to write even the shortest of blog posts becomes more difficult, but as we are looking for more staff yet again to help solve our clients growth plans, I thought I cover some of our inventive ways we have dealt with growth, and how we differ from most other software development companies.

Developer driven


When I started the original consulting company over 10 years ago, I focused the work on software development which tried to solve complex problems and deliver maintainable systems that could grow over the years. If we needed design work, it would be either outsourced, or done in partnership with similarly focused companies. This means our business has long been based on repeat business from a group of growing companies

Over the last year as we have grown to three people, and still as busy as ever, that focus has become even more clear, as I have written before, our competitive environment consists mostly of design companies with limited interest in producing quality software, rather quickly throwing trash out the door, getting paid, and moving on to the next sucker.. (sometimes we get to clear up that mess...)

Applying software development to our own processes.


Our business is no different in many ways from our clients, we are always attempting to optimize our processes, reduce time spent on meaningless tasks and ensure that everyone is spending their time adding value to our clients businesses. In software development this involves a number of core pieces of infrastructure, Revision control, review systems, task tracking, time billing and accounting. The result and aim of these are two pronged, ensuring that the quality of work being produced is worth the money we are being paid for it, and making sure our clients are aware of their current and outstanding expenses.

While we have the above processes in place, they often are not applied in exactly the same way that the industry has come to expect. This is mainly due to the way that rather than going for off the shelf solutions to our problems, we have tended to develop the tools in-house (a great way to perfect your skills often). While this smacks of NIH (Not invented Here) syndrome, and I can not say that I do not worry about that sometimes, the result is that our processes drive the design of our tools rather that our tools designing our processes. 

At present one of the key differences  is our approach to the classic developer focus on task driven commits. As this blog has mentioned before, we do not do task driven commits (gitlive). Every single file save is committed into our revision control system. While this may sound a bit strange, It has significant benefits for all involved. After so many years of working I can not tell you how many times that work has been lost due to accidents. Since we are getting paid for this work, any possibility of loosing it would be costing us money (or if we where not so ethical, our clients, which sadly i suspect happens all to often in the industry.).

I have been considering for a while if we should merge this workflow into a more task driven commit methodology, but as what I though would be a short term fix, seems to have re-in-forced this idea that we should not go down that route. This short term fix was the concept of daily commit messages. In a normal task driven process, the commit that fixed the issue would be appended to the ticket (and frequently emailed for review), it could then be reviewed as the issue was signed off.

We did try this on one project, however what resulted was a constant back and forth on multiple issues, and a very time consuming review process. This using the most expensive resource in the company, senior developers. So in switching to daily diff's there was only the need to review the changes for each project. In this way it was also possible to communicate not only serious code fixes, but also advise on better practices. without having to throw that into a tracking system (Although email in some respects is always a tracking system).

The full stack experience


Our new staff over the last year have grown considerably, comming from a classic Hong Kong software development environment, they had ended up focused on a single area of the development process. They would work on projects for weeks and come back with a result, often having to persude, or wait on information from other teams working on a different area of the same project.

I regard this as one of the worst industry practices out here, so over the period they have been working at Roo J Solutions, they have been thrown in the deep end with every part of the standard development stack, front end, back end and database. Tasks are frequently day or even hour based, however working as a team now, they can pass the learning of the new tools around. Always having my knowledge as a good backup. To the suprise of someone who had worked on that team with them before, they not only did not sink, but swam very well being given new challenges. 

So if this sounds like a interesting place to work and you or someone you know would like to be attacking our challenging new projects, please pass on the post or email me at jobs@roojs.com, with the usual information (If I have to tell you.....)
Posted by in at 2013-01-28 00:00:00 | Add / View Comments()

Interesting Problems.

If there is one reason I would put down to why I still enjoy coding after all these years, it is the pleasure finding a really challenging problem and being able to solve it quickly and efficiently.

This week saw one of those problems, strange, obtuse, and to most non crazy people would seem to be an odd thing to get excited about. It all started with going through the requirements list on one of our projects.

As I've mentioned before, we are building quite heavily ontop of Xtuple, a Web based GUI using the RooJS Toolkit, most of that part has been just process orientated - add this feature, and it just works. But some of the implementation process has been a challenge.

The company we are working with has 2 main offices (and more comming on line soon), and we have successfully migrated them off of netsuite, which in reality made an absolute mess of their accounts. When migrating to Xtuple (which in essence is a postgresql database, with a seemingly endless number of table triggers, stored procedures and views), we concluded quite early on that setting up a seperate instance for each office would be the best way to go.

Core issues like difference currencies in each office, so the chart of accounts can be reported each year in the local currency to the tax department and auditors, along with the different end-of-year tax reporting made this a simple decission. The otehr issues was that the basic installation of Xtuple does not really support Multiple companies in the Desktop UI (you have to pay for that feature). 

So as we are now live, and just about finished with the rollout issues, we are now on to the more critical things for long term operations - Management reports (and a nice dashboard). 

The issue that raised it's head was that the company needs to see consolidated Balance sheet and Income statements. It did not take to much time to call the internal methods in Xtuple 'financialreport()' and in PHP convert this to JSON so that a master script can call the report in both systems, and merge them together. 

The snag came later when we realized that the resulting report was a little off.. Due to the magic of differeing accounting periods.

Posted by in at 2012-11-02 00:00:00 | Add / View Comments()
   (Page 1 of 22, totalling 225 entries)    next page »

Follow us on