Search the Bible and Taggloo Library

Taggloo has previously been updated to include results from selected books held in the Taggloo Library in translation results. Whilst this was useful, Taggloo now goes a step further in search.

Book search

You can now search a Book within the Taggloo Library using the search-form at the top-right of each page. This allows you to discover words and phrases without going via the route of Translation.

A subtle improvement that has already been made available is the highlighting of search results in the text, so when searching for “thie”:

Highlighted search result

Underneath, Taggloo fully supports any number of books and articles which will hopefully be made available soon. If you have any content that you wish to be published, get in touch.

Alas, the translation and searching is slower than I’d hope. This is being worked upon to strike a balance between performance and affordability. Hopefully there’ll be some modest improvements soon!

Translate and search the Taggloo Library (and The Manx Gaelic Bible)

There is a wealth of Manx Gaelic literature available for access both on paper and on the web. Taggloo launched a Library service last year, with what is possibly the best starting point for any library, The Bible. The Bible is a time capsule, showing us how the language was used when it was the primary language of the island – even before people started to use their own language in a written form themselves.

Using the Library function, it’s a short jump to providing the ability to search and translate the Taggloo corpus. You can enter a word or phrase for translation as you usually would and receive the results. If you’re interested in a deeper translation and understanding of the word or phrase in literature such as The Bible, you can Extend your search by selecting the book(s) you want to search and clicking the Search button.

Taggloo Library Translation and search

The translation and search has been deliberately broken into two steps, which was a carefully considered pattern to balance convenience with performance. Searching an entire book (or set of books) can be taxing on the indexes so results from books are held back unless you need them.

Once you’ve performed your search, you can expand the results as you would translations by word or retrieve the entire set of results.

Ayns y toshiaght

Below each result will be the translation (if available) and the book, allowing you to click to jump to that point in the text.

The Library function can support many texts with differing levels of translation. The next step in the Taggloo story is to provide the tools to allow additional texts to be added into the Taggloo Library, providing even greater insight into the words and translations of Manx Gaelic.

Pass the fork

Teams often work on shared code, shared resources and in shared time. We have ways of managing this, such as source control, one of the first requirements for software development maturity (falling within Levels 2 to 3 of the CMM for Software). However, not everything is easily integrated into such a process.

Developing on the example of source control, source control presents challenges that the mature team will be able to identify and overcome through the use of best practices or their own devised and agreed processes. Shared assets such as legacy systems, premium-licensed resources or even databases often exist outside of source control leaving the team requiring confidence that one developer’s work on that shared asset won’t affect others.

Meet the fork.

The DB Token of Power ("The Fork")

With the fork, a team member can wield power of access to a contended or non-source controlled asset such as database schema changes, SharePoint server configuration, leverage of a single-user licence service or other lock-required activity. The fork acts as a physical action and visual cue in the physical world, representing the reality within the virtual or abstracted world of source code, databases and servers. As a team member reaches for the fork, their wishes are explicit (“I have the fork”) and may be “blocked” by any other team member (“Oi, hang on, I need to do something first”). Without the fork, no changes may be made – or would be expected to have been made by the rest of the team.

Use of a token in this manner is predicated on the collaborative capabilities of the team, perhaps requiring that the team are co-located, small and cohesive. Such team environments aren’t always possible or available. Teams that are not co-located, are perhaps too large (spanning more than one pod of desks) or lack a cohesiveness that is conducive to casual conversation would inhibit the use of such a token; though in this case, one must answer much larger questions about why are these people working on contended assets?

There are alternatives. Use of a shared chat channel for the team such as Slack with an agreed protocol (even descending to the “claim” protocol introduced in The Walking Dead TV Show) would overcome the overly-large, distributed and communication-inhibited team; though this would require a level of buy-in or enforcement by a commonly accepted leader.

We’ve used the fork to great effect. Merging of sensitive assets such as Entity Framework .edmx files (this project has not yet made it to Code-first) can result in a whole world of pain if two developers tackle two work items that are either contradictory or contended. It’s simple and promotes added cohesiveness within the team. Our token was chosen based on what was sitting in one of our drawers and this remains a shared experience within the team and contributes to our mutual social credit.

Of course, you don’t need to use a fork, any token will do, so long as the understanding across the team is consistent and mutual. Such tokens have been in use for years. Ever since the 19th century, and remaining in use even amidst today’s modern computer-controlled signalling, railways have used the token to guarantee safe access to controlled sections of track to prevent collisions.

 

 

 

Source control your relationship

pipe-cleaner-people-1177056-640x480An interesting parallel was drawn by a colleague recently between relationships with your significant other and source control. Both need total engagement by all parties and both can quickly unravel when a lack of commitment or adherence to the agreed guidance and conventions isn’t all it could be.

There is the sitcom-esque “commitment issues” whereby either party is afraid to really commit to a relationship either monogamously or sealing the deal through marriage. Programmers who exhibit a tendency to hold on to their code, avoiding regular commits, store up problems both for themselves and their team.

Maybe your other half feels that she has been put on the shelf, forgotten about and fleetingly appearing in your life as you pass by over dinner or scanning the repo. And you better make sure you get your [file]names right first time if you want to avoid a rapid appearance of irreconcilable problems.

Source control remembers everything you did, all your commits, experiments (branches) and log comments (not as private as one might like). “She” is equally able to remember all your mistakes with unnerving accuracy. Your branches (experimental flings) are on your permanent record, as are your seemingly innocuous comments logged (“I’m fine”). When differences approach the irreconcilable, you start reaching for the Patches.

Any experiments you may have on your branches/flings, are always a time of nervousness to merge back into the trunk/relationship and can rarely be fully re-integrated. Conflicts and lost assets are inevitable. “She” prefers exclusive checkouts, you might prefer a more … distributed approach.

Perhaps where the metaphor starts to fail is the real-world relationship’s difficulty of reverting commits. A programmer can quickly back out of some embarrassing moments in code with a right-click, returning silently to the state of their source and team relationship as if nothing happened. On the other hand, “she” remembers all your mistakes and your attempts to repair them.

By the way, to save embarrassment, this tongue-in-cheek parallel is drawn with no reference to any relationships past or present, real or imaginary. So, no need to perform any Diffs here.

 

Introducing Agile to the corporate dark matter development team

Photograph of team with joining handsThe challenges of the Agile team within the traditionally-managed and hierarchically structured organization are discussed extensively in research. Artefacts of the burgeoning, hierarchical organisation such as company policy (“we don’t do it that way here”), imposition of arbitrary and incompatible standards, command-control management and poor project manager integration all contribute to inhibiting Agile operationalisation (1, 2, 3).

Alongside this research, I have come across some of these challenges, along with a few others surrounding the personal nature of the team. As a new member of a team, and having been indoctrinated by a fine Scrum trainer, it would be easy for me to lose friends and disenfranchise people had I preached to my new team about how they were doing it wrong and how Scrum would fix all.

But this is not about rehashing problems. Instead, I’ve compiled some lessons which may help others.

In introducing these, I could conclude right now with … Take it slowly

Understand why the team do what they do

It would be ignorant and offensive to assume that archaic processes continued to be followed due to lack of awareness or skill. There is likely to be a valid reason for filling out release forms, why users don’t get engaged or solutions are dictated before the problem is understood. Taking some time to observe and understand through casual discussion is ideal for encouraging titbits of information to be revealed which could explain the history of internal practices and procedures. Perhaps the reason is long forgotten or no longer relevant. Judgement should be withheld, lest you be judged yourself.

Prepare your tools

Creating a new process is made much easier if there are tools surrounding the process that allow the team to fall into the pit of success. I’ve used JIRA in these situations, which has been a first step in formalising tasks from which a backlog may be created. As requirements come in, the task of distilling tasks into User Stories (using the spirit of the terminology if not the definition) and then sharing them out to the team without the dogma of story points, retrospectives or stand-ups has allowed a degree of task ownership and collaboration to emerge over the medium of the tool. JIRA has an API, so if the wider organisation insist on their legacy tool to be used, it can be integrated within a wider process.

Embrace, Extend …

Stopping short of the entire terminology reputedly used internally by Microsoft, I’ve found that it is the team that determines the success of Agile, not the method. Therefore, I’ve embraced the Agile dogma such as Scrum, and extended it – or rather – evolved it, according to the personal nature of the team. During forming, storming and norming, personalities within the team are explored within a professional context, allowing me to learn a lot about the individuals and their motivations. Attempting to mandate process according to Scrum-doctrine will only serve to extinguish Agile all the more quickly and perhaps professional relationships within the team.

Know the assumptions of your method

Methods such as Scrum make sweeping generalisations across industries and fail to state their assumptions. Outside of the software development company, multi-project developers who have to balance ongoing support requirements are widespread. Scrum, and the admittedly useful and revealing metrics that fall out of it, assume that 100% of the time of developers is spent on the code. It’s all about the Story Points, NUTs or even breeds of dog (“that will be 2 Labradors and a German Shephard”) but this does not take into account time spent outside of the project. At any given moment, the **** could hit the fan robbing the project of velocity which would be unaccounted for in the retrospective reports. Equally, how well does Scrum work within a portfolio? Models like SAFe claim to allow multiple projects managed using Scrum-like techniques, but this is not necessarily the same contended resources.

 

The key to the success that I’ve seen with this is to introduce Agile principles gently. No great switch was needed from which all projects would be Agile. Each project slowly became more Agile than the last and the surrounding individuals (managers, Business Analysts, etc.) are understood first and introduced second. The Business Analyst is perhaps your greatest chance of success of implementing Agile concepts within the hierarchical organisation so they need to be brought on-board at their own pace. I’ve learned to listen and understand first, based on which, one can start to make the case using what can be highly adaptive models that are made to fit the team, not vice-versa.

 

Keeping projects warm in multiple project teams

Whilst the project management gurus and Agilistas talk about methods such as Scrum as if developers only sit on a single project, the reality is that they don’t. Developers are charged with concurrent projects, each with their own constraints which require autonomous scheduling of development effort according to resource availability or even what is considered easier to focus on at the time. On top of this, the inevitable support obligations of applications previously delivered will undoubtedly pick away at development time. Sure, this is not an ideal situation and is known to be an inhibitor of Agile, but it is often reality for those developers not working within sexy start-ups with a single product or the larger software houses.

Within this multiple project, support intrusion reality, it is easy to fall in to the trap of starting projects with much enthusiasm but then seeing the initial sprints turning into a drudge as developers fight to keep the project and their own enthusiasm alive amidst the chaos of a demanding multi-project portfolio. Priorities change, resources are re-allocated and interest wanes across the business.

My suggestion in this circumstance is to keep project iterations small, and keep them warm.

Consider this example team, with their own project portfolio.

Agile-Lean Portfolio

Agile-Lean team Portfolio (click to expand)

The projects are spread across the team members with multiple developers able to work on the same project. Projects are worked on in fixed timeboxes, which allows developers to apply Scrum-style working to generate velocity metrics that help improve predictions of future performance.

Longer projects cause developers to “go dark” from the team and the client. They are less visible and accessible to the client and become less available within the team’s portfolio of projects without sacrificing their existing project effort and therefore attention. Instead, breaking the projects into smaller iterations and spreading across the team means they can be switched in and out predictably and with minimal friction.

Johanna Rothman suggests using a “Parking Lot” to hold projects in a warm state in between sprints. This provides an ideal opportunity for users to become involved and fulfil their obligations as part of an Agile project and provides the client with a predictable obligation within an existing workload as part of their day-to-day business.

Developers can be switched in and out of projects, allowing for cross-skilling and redundancy for support obligations. In the three-developer team illustrated, each project has a minimum of two developers who have worked on the project and who would be able to support it.

The team lead will remember when their team has booked their holidays, right? Adding them to a project plan helps visualise the team member’s absence ahead of time, allowing developers to collaborate beforehand about possible risks or support obligations and applies redundancy.

The method (Scrum, XP, Kanban, etc.) is unimportant. I’m not a consultant selling ideology, this example is based on experience of working on multiple software teams.

  • Balance between developer focus and availability to the portfolio. Developers work best with focus on the task, but must be available to the portfolio often at short notice. Allowing a project to be parked facilitates selection of the most-able developer in their own individual schedules within their own timeboxes to attend to an unexpected task. Equally, having fixed timeboxes allows the business or client to be promised attention by a point in time, backed up by a known and published schedule.
  • Maintains sharp focus for developers who must develop within shorter iterations. Shorter timeboxes bring sooner objectives and deliverables. Tighter management of developer effort, particularly in larger projects, will help reduce drift in terms of scope and attention. This also reminds the business/client of their own role on an ongoing basis, with regular status updates and predictable resource requirement.
  • Less cost for developer to rediscover context. Distractions cost time which cost money, though this is rarely quantified. The reality is often that a developer will need to context switch from project-to-support-to-project-to-chat-to-project. But this can be reduced and controlled. By limiting the demands on a developer’s contextual concentration within a period of time (timebox) to a single project, one can maintain a developer’s attention on the day-to-day support and collaboration requirement but maximise attention per project. Perhaps individuals may be designated “hot” for support tasks within a timebox on a rotating basis to minimise team-wide disruption.
  • Keeps the user engaged. The role of the customer is often misunderstood and under-represented in Agile. Agile approaches are dependent on early and regular contact with the customer to gather feedback on project deliverables thus far. However, the client and wider organisation already have a job to do which the development team must respect. Keeping the cadence of user involvement to a regular and predictable timetable helps the user plan their own time within their existing obligations. It may be unsuitable for the user to be expected to contribute to projects at the end of every sprint, but regular contact will keep the user engaged, particularly if they can see improvements.

There are frameworks and whitepapers and methods and processes and the rest, but these don’t interest me. What works for the team is what works for the business. However, perhaps this structure may be integrated into your processes, formal or not. The use of timeboxes enables integration into a wider process, such as the SAFe Framework, where individuals and teams can be “plugged in” to the wider project as required.

 

Reflecting on the state of social media on the Isle of Man

Photograph of Social Media Club dinnerAs a small island, separated from the mainland but connected to the world, the development of social media has been an interesting story.

Whilst social media had been adopted as the platform of choice for younger generations, companies were keen on understanding how to reach these demographics on their own platform and how to continue with a positive engagement. The Social Media Club was developed as a way to develop ideas and promote best practice across the social media world.

As part of this, the island’s Social Media Club met every month, ranging in number from 4 to 20 and always promoted interesting discussions, particularly with social media hitting the news for topics such as bullying, privacy and the corporate movements of the new burgeoning tech sector.

We had some successes, introducing users and companies to social media. We also had two successful Twestival events which only ceased due to the organisers’ bizarre brand-grab, raising one of the largest amounts across the world per-capita.

Where has the island come since?

Perhaps we can claim the island has reached a level of adoption which suggests maturity gained through usage, experience and even groups such as the Social Media Club lunches.

Inevitably, marketing companies have adopted the paradigm, specialising in results-based marketing and avoiding the broadcast or fire-and-forget method of reaching out to customers that may otherwise be used.

Manx Radio recently started reading out contributions from social media on their Mandate show, providing an additional channel to contribute to live shows other than the email and telephone older generations may be used to. (It’s interesting that email is now seen as an archaic medium for newer generations.) You get a better class of mental on Twitter!

Even the Isle of Man Government have jumped on, with differing levels of success and engagement according to the topic and department. Between engaging with users as tax payers and delicately straddling the line of individual privacy and the professionalism of the department, it’s been refreshing to see a little bit more transparency.

Further signs of maturity on the island is the consideration of the effect of social media on the island’s unnaturally small juries. Chris Robertshaw has embarked on an exercise of determining whether enough people are in the juries and how the judiciary will mitigate against influence from what is a tightly bound island community online.

In reflection, we remain a separated island but are very much more connected.

 

The role of ethics on a licence to practice

Just because it's dark doesn't makeit unethicalI’m firmly of the opinion that the IT industry should have a licence to practice, or at least a recognised qualification or membership that indicates that you are serious about your conduct within your career. The best body for this as it appears to stand in the UK is the British Computer Society. Unfortunately, the BCS remains  an embarrassment and continues to fail to make an impact on employers and professionals in respect of a licence to practice, or even recognition of any ethical standing. Despite their reinvented Chartered IT Professional status, they remain invisible and irrelevant.

IT is an industry that now touches us all and the risk of our data traversing physical, network, jurisdictional and geographic boundaries has come into sharp focus with an increase in the number of data leakages and ‘hacks’ that serve to showcase anything from a security hole to the hubris of an anonymous script kiddie. As an individual working within this profession, one should have to commit to exercising every possible effort in maintaining one’s own ethical position, which would include their role in ensuring the projects within which they work make every possible effort to perform to the same standard. The BCS has their own Code of Conduct which attempts to create a position of professional and ethical performance but this does not offer any real sanctions other than being “struck off” as a member of an entirely irrelevant register.

Had a workable and enforceable code of conduct or ethics existed, would we have seen any of just a few of the recent scandals?

  • Volkswagen’s discovery (not admission) that they had used software to cheat in emissions tests for their vehicles under specific test conditions required effort by at least one developer who knew exactly what they were trying to achieve. These developers breached ethical considerations which surely span cultures; thou should not lie. VW’s American CEO Michael Horn claimed in congress that it was two software engineers that came up and implemented the cheat. Of course, we should consider that they may have felt pressured to implement the cheating software, but had there been a substantial professional body behind them they may have felt confident in blowing a whistle.
  • Adobe had 153 million accounts exposed in 2013 which revealed usernames, email addresses, encrypted passwords and unencrypted password hints. Unfortunately, the passwords were encrypted weakly meaning it was fairly easy to brute force the encryption based on repeated sequences of data. Coupled with an unencrypted password hint which only serves to undermine the weak encryption and it makes one wonder whether the developers stopped and thought, “are we doing enough?”
Then there is the incompetence:
  • This year saw 780 people “outed” as HIV sufferers by a leading sexual health clinic. The cause was a basic human error of pasting the email addresses into the wrong field. It’s very easily done. This very basic administrative error has major repercussions on lives.
  • We have our own case of gross incompetence on the Isle of Man. Earlier this year, hundreds of individuals’ email addresses were shared across email, again as a result of the basic administrative error of using the wrong email field. What happened? The Data Protection Commissioner took no action and all that could be seen were some red faces.
Such examples of incompetence are not malicious, but they are indicative of lack of training and oversight. Had ethics been considered, any transaction with any personal data would have been conducted with the greatest of care. Even more shocking is the lack of action by a Data Protection Commissioner whose very position is based on ethical and competent use of data.

I did miss one recent high-profile hack, that of Ashley Madison. This raises an interesting point. Within an ethical framework, where does one’s professional ethics come into play? Personally, I believe that as long as the programmers were honest in what they were doing, regardless of society’s view on the ultimate effect of their actions which are quite rightly extremely serious, then they should feel confident in their professional conduct. The programmers have apparently gone to great lengths to safeguard the identities and security of their clients. We still don’t know how the hack was performed or whether it was an inside job, but based on the news and discussions, security was seemingly tight. This notwithstanding, their managers’ decision not to delete data from individuals paying to be deleted is blatantly unethical and these individuals should feel the full force of the law as punishment.

 

Using an anti-pattern still enhances your maturity

Programming has approached a level of professionalism that suggests we now spend a lot of time meta-programming, naval-gazing and writing a whole lot of complex code just to avoid smells.

Meta-programming could be described as programming about programming. As our tools get more advanced and our systems get faster, we can now write code that writes code and write code that analyses code. What’s the point? Visual Studio has finally integrated the Roselyn Compiler-as-a-Service feature which brings the compiler in as a first-class citizen so you can generate code and analyse it from within your own program. But wait, the last time I looked, it was an anti-pattern to dynamically generate code.

This self-analysis of code has otherwise been a manual process, supported by burgeoning communities of self-aggrandising architects such as those gaining increased scores on sites like Stack Overflow. Thou shalt not code in JavaScript in an imperative fashion, though shalt not use global variables, and it goes on. We’ve got to the point of intellectualism that we are able to create arbitrary levels of maturity and compare ourselves and others against them with little consideration of “why?”.

In order to leverage new features, avoid the judgement of our peers or even ourselves, we’ll go to great lengths to create patterns of best practice which decouples concerns, increases testability and complies with the latest guidance of our peers – however much work that may take. We must avoid the Anti-pattern, lest we be judged.

But the Anti-pattern is still a pattern, so suggests some level of thought and maturity.

I’m reminded of the Capability Maturity Model (CMM), which is a model of maturity applied to organisations to identify whether their processes are chaotic or structured so are repeatable, measurable, testable and therefore able to be improved. Of course, the software industry hasn’t allowed itself to avoid its own naval gazing and has come up with various mirror models. Many of these are arbitrary and perhaps form an extra string to a consultant’s bone, such as the Software Development Maturity Model, the Software Assurance Model, and of course there would be an Agile Maturity Model developed by … a consultant.

We’re perhaps too quick to judge software code and not understand why it is what it is.

As a developer, one of my struts for my professionalism is the decoupling of concerns. This is simplified such that no module ultimately depends (or even knows) about any other module. You sort of “wire it up” during a bootstrapping process. At the moment. We used to think that modules should know about each other, but perhaps on a more restricted scale, so the database would be “known” by the behaviour, but not the presentation. Now, technology has come so far and developers’ minds have grown so large that we now realise this is bad practice. So we use Dependency Injection whereby a single element of the code performs the wiring up, invisibly, automatically and somewhat magically. You don’t need to know how, just why. Wait … what?

Dependency Injection develops on the previous best practice, the Service Locator – which is now an anti-pattern. But I know how and why with that pattern. But it was a pattern. A Service Locator could be regarded as a central authority for identifying what modules in your code did what. You’d go to this and ask for the code to access the database or perform a particular process. It was, in effect, a global variable which itself had developed from previous practices.

Last night, about 2am, I found myself writing a service locator Anti-pattern, direct from Microsoft’s evangelists, no less. This is the NavigationService (the clue’s in the name, I realise) which was passed around as a property in view models within Windows 10 apps using the Template10 project. I immediately recoiled. Sure, they’re passing it around as a property, but it is still a Service Locator. But it is also 2am. A pattern’s a pattern. And I went with it.

The fact that there is a scale of these practices, each time evolving to improve their perceived professionalism based on a fad or a consultant’s USP, suggests maturity. Using the Service Locator, I deliberately considered the risk (code smell, limited decoupling, global variable in all but name) with the benefits (it’s 2am) and strategically decided on an outcome. According to the ubiquitous CMM this at least puts me at level 3 – it’s a defined process that is documented and can thus be improved.

Best practices avoid code smells and become themselves anti-patterns. You just need to look to spot this moment and switch tactic at the right time.

The maturity here is the consideration of the time, the rapid delivery that is so craved by Agile techniques and the enthusiasm to get to the next problem and using an anti-pattern – but knowing why and committing myself to returning and improving my own process later. I come across anti-patterns regularly, after all, no developer ever said “wow, the previous developer’s code is certainly better than my own.” But I stop and think. Considering how busy I am now, could this not be where my predecessor found himself? Was that the best practice at the time?

So my Service Locator Anti-pattern is justified. Publicly. Deal with it.

Increased browser compatibility, more media and a new API

Taggloo hasn’t had much visible changes lately, but eagle-eyed users will have noticed that the build date has been changing. As promised, moving Taggloo to the Microsoft Azure platform enables much more rapid and regular changes, not all of which are obvious.

Microsoft Edge support

Keener users will no doubt have started experimenting with Microsoft’s new Windows 10 operating system. Windows 10 represents a key strategy change for Microsoft, not least of which is their unceremonious dumping of Internet Explorer in favour of Edge for the consumer. Edge is a “new” browser in that it is almost a rewritten browser, well, it represents the latest of the code in Internet Explorer and dumps a lot of baggage in the process.

Taggloo remains compatible with the latest browsers, including Microsoft Edge. This will carry across to other platforms using Microsoft Edge such as XBox One and Windows 10 Mobile. Of course, WebKit (Chrome) and Firefox remain supported across screen sizes. Hopefully you’ve seen the responsive design work well across desktop, tablet and ‘phone.

Increased playable media items

Taggloo has over 10,000 indexed media items, allowing users to hear the pronunciation of thousands of words within the dictionary.

Media Items

For those users still on Internet Explorer, which has limited support for the HTML AUDIO element that is used for these media items, you would probably be left with:

Invalid source screenshot

As part of a lot more of somewhat invisible work, the likelihood of this being shown is much lower. Using the new Taggloo API, existing media items have been indexed, transcoded and re-indexed to maximise availability across devices and browsers.

… About that API

An API (Application Programming Interface) provides developers with the opportunity to leverage the functionality and data within a web site for their own purposes. Taggloo’s new API enables developers to access the indexed Manx Gaelic resources to build and extend their own products and experiments. This represents an exciting opportunity for Taggloo, which can now be integrated into other web sites, “apps”, Internet of Things (IoT), wearables and much more.

The API is currently in BETA, which means that you’re welcome to go and play and see what you (or your developer friends) can build. We’re currently tweaking the performance of the API and adding more functionality every week, hence the BETA stage. You can have a look if you’re so inclined at http://taggloo.im/developers. The API currently covers about 75% of the entire functionality of Taggloo and will emerge from BETA before the end of 2015.