Archive

Posts Tagged ‘hexlicense’

HexLicense, Patreon and all that

September 6, 2018 Comments off

Apparently using modern service like Patreon to maintain components has become a point of annoyance and confusion. I realize that I formulated the initial HexLicense post somewhat vague and confusing, in retrospect I will admit that and also take critique for not spending a little more time on preparations.

Having said that, I also corrected the mistake quickly and clarified the situation. I feel some of the comments have been excessively critical for something that, ultimately, is a service to the community. But I’ll roll with the punches and let’s just put this issue to bed.

From the top please

fromthetopI have several products and frameworks that naturally takes time to maintain and evolve. And having to maintain websites, pay for tax and invoicing services, pay for hosting (and so on), well it consumes a lot of hours. Hours that I can no longer afford to spend (my work at Embarcadero must come first, I have a family to support). So Patreon is a great way to optimize a very busy schedule.

Today developers solve a lot of the business strain by using Patreon. They make their products open source, but give those that support and help fund the development special perks, such as early access, special builds and a more direct line of control over where the different projects and sub-projects are heading.

The public repository that everyone has access to is maintained by pushing the code on interval, meaning that the public “free stuff” (LGPL v3 license) will be some months behind the early-access that patrons enjoy. This is common and the same approach both large and small teams go about things in 2018. Quite radical compared to what we “old-timers” are used to, but that’s how things work now. I just go with flow and try to do the most amount of good on the journey.

Benefits of Patreon

The benefits are many, but first and foremost it has to do with time. Developer don’t have to maintain 3-4 websites, pay for invoicing services on said products, pay hosting fees and rent support forums — instead focus is on getting things done. So instead of an hour here and there, you can (based on the level of support) allocate X hours within a week or weekend that are continuous.

4a128ea6852444fbfc89022be4132e9b

Patreon solves two things: time and cost

Everyone wins. Those that support and help fund the projects enjoy early access and special builds. The community at large wins because the public repository is likewise maintained, albeit somewhat behind the cutting edge code patrons enjoy. And the developers wins because he or she doesn’t have to run around like a mad chicken maintaining X number of websites -wasting more time doing maintenance than building cool new features.

 

And above all, pricing goes down. By spreading the cost over a larger base of interest, people get access to code that used to cost $200 for $35. The more people that helps out, the more the cost can be reduced per tier.

To make it crystal clear what the status of my frameworks and component packages are, here is a carbon copy from HexLicense.com

For immediate release

Effective immediately HexLicense is open-source, released under the GNU Lesser General Public License v3. You can read the details of that license by clicking here.

Patreon model

Patreon_logo.svgIn order to consolidate the various projects I maintain, I have established a Patreon account. This means that people can help fund further development on HexLicense, LDEF, Amibian and various Delphi libraries as a whole. This greatly simplifies things for everyone.

I will be able to allocate time based on a broader picture, I also don’t need to pay for invoicing services, web hosting and more. This allows me to continue to evolve the components and code, but without so many separate product identities to maintain.

Patreon supporters will receive updates before anyone else and have direct access to the latest code at all times. The public bitbucket repository will be updated on interval, but will by consequence be behind the Patreon updates.

Further security

One of the core goals on Patreon is the evolution of a bytecode compiler. This should be of special interest to HexLicense users. Being able to compile modules that hackers will be unable to debug gives you a huge advantage. The engine is designed so that the instruction-set can be randomized for a particular build. Making it unique for your application.

patron_asm1

The LDEF assembler prototype running under Smart Mobile Studio

Well, I want to thank everyone involved. It has been a great journey to produce so many components, libraries and solutions over the years – but now it’s time for me to cut down on the number of projects and focus on core technology.

HexLicense with the update license files will be uploaded to BitBucket shortly.

Sincerly

Jon Lennart Aasenden

 

 

Hexlog, building a better logging system

October 15, 2016 Leave a comment

Its been quite a busy couple of weeks for me. HexLicense has finally gotten a well deserved update and (drumroll) we have ported the codebase over to Firemonkey. I have deliberately waited a while with the Firemonkey edition, because compilers usually need a couple of releases before they become stable. And the same can be said about runtime libraries (I should know, I have created a few). I wanted to use FMX earlier but, it kinda died on me so many times that I gave up. Thankfully this is no longer the case and Delphi XE Seattle is a joy to work with.

Ironwood prototype

Ironwood prototype

Also, one of the coolest things these past weeks was returning to Smart Mobile Studio as a user. It’s really quite an odd experience because you get so locked into “author” mode when you have worked on a product for so many years. So when you sit down to actually use your own program as a means to an end, it’s a very different experience from looking at it purely architecturally.

I really love what we managed to do with Smart Mobile Studio. That might sound disingenuous since it originated with me, but somehow we captured something; some sense of creative freedom that I cannot find in giant productions like Visual Studio or QT C++. Naturally I’m biased, but I’m no stranger to self-critique either. But the speed at which I knock out a HTML5 or mobile application with Smart Pascal is just way beyond anything I can do in any other devkit. The only other development platform that have the same feel to it is Mono C#, which I love because it doesn’t contain all the .. bloat, I guess is a word, that large production environments insist on giving you. I mean, fire up visual studio and you have so many options – half of them that you will never use unless you specialize within a particular dicipline – that they just get in the way.

Anyways, Hexlicense “Ironwood” was written first and foremost in Smart Mobile Studio. We have started to port the code over to Delphi to make the Xmas deadline, but honestly: I’m so glad I could use Smart to prototype this product, because it would have taken me twice as long in Freepascal or Delphi. I’m not even sure I would have bothered if Visual Studio was my only option. Seriously.

So you may be wondering: why on earth would you implement a licensing system in JavaScript? Well that’s the cool part! Right now most licensing systems are native only. Which means that if you want to really get control over your software you have to fork out for a virtual host, if not a physical server box. The price difference between a node.js hosting solution and a native hosting solution is substantial. So implementing a version of our HexLicense server in Smart Pascal + node.js will save my customers the expense. It also means they can host the server on whatever operative system they see fit. And once again, the price difference between a Linux host (Ubuntu is wonderful to work with) and Microsoft Windows is still a factor.

Coding it in Smart Pascal also opens up the door for license based access to HTML5 based applications, be they compiled to native via Phonegap or Adobe build services or just running in a browser. So once again our JavaScript virtual machine formula get’s it right. And it’s magnificent to play with. Not a day goes by that I don’t learn something new and exciting about JavaScript from object pascal, which is paradoxical. I know.

Back in the saddle

For the past few years my life has revolved around Smart Mobile Studio and the companies I have worked for (a.k.a “the day job”). It must be at least 4-5 years since I actually sat down and built products, delivered components and offered up my services as a Delphi software architect. There havent even been any time for consulting or system design. With a full day job, two kids and a product you live and breathe for there is a limit to how much you manage. Add to that my back injury 4 years ago which rendered me unable to even walk and you get the picture; Thankfully my back is getting better. I do two rounds of boxing every week (or try to) and that has done more for my back than all the doctors and their witch-craft medicine combined.

It feels so good to create new products again. Products that are doable within a reasonable time-frame and that solve real-life practical problems (as opposed to having to solve potential scenarios that havent even occurred yet: the burden of the RTL architect). So while HexLicense for VCL and FMX is in the store, Ironwood is being ported to Delphi – I have decided to wake up another component-set that I initially created for myself. One that deals with a very practical and hands-on challenge, namely: HexLog.

HexLog

Many years ago I was working for Hydro, which is the biggest oil company in Norway. Without getting to detailed (or breaking my NDA) logging was one of the problems we faced. With more than 50 Windows services communicating (read: 50 potential sources of bugs), the company’s lack of proper logging – logging in a format that made sense to people other than us developers (like system administrators, super-users and even insurance companies interested in locating where something broke down) made it almost impossible to work with the codebase.

So one day I had enough and sat down in my spare time to write a modular, thread safe, component based logging system that didn’t just “log some info”, but it did so by proxy. Meaning, that the writing mechanism(s) were isolated in separate components, abstracted from storage – which was isolated in other components. So when we needed XML logging we just hooked up the XML writer; when we needed RTF logging we hooked that up (and so on, for numerous formats).

You would think that Delphi developers in general had logging under wraps right? That is sadly not the case. Some people are very good at logging and have made it into a habit. But more often than not when I’m hired by a client – what do you think I find? Yup, plain old vanilla text-file logging. Which is fine as long as the coders have spent some time making sure the basics are in order. Sadly that is so rare it almost frightens me. Especially when I’ve upgraded software used by pharmacutical companies, doctors and organizations that really (really!) should do full journaling regardless of bugs or errors. In fact Norwegian law demands it in some cases; especially when medicine and prescription drugs are involved. If a doctor or nurse prescribes the wrong medication and a patient dies, the insurance companies will have a field day if there is no logging according to standards. And should it turn out to be the software’s fault.. well, let’s just say there is a reason only large companies operate with “within the hour response time” in their service agreements.

So what are the criteria people tend to forget?

  • File locking issues. It will happen the moment more than one process or thread targets a file
  • Making sure the information that is logged is organized by sections, visually distinct in the file
  • Making sure time and dates use UTC or ISO formatting
  • Logging the actual user, not just the program identity
  • Using mutexes and read-write synchronization when multi-threading is involved
  • Avoiding interface communication from threads without proper understanding of calling conventions and compartment schemes
  • Using memory mapped files rather than torturing the filesystem with an onslaught of IO calls
  • Use tab indentation to make the logs easier to navigate for the human eye
  • The list goes on ..

The most important oversight is not on the list, it’s actually something as simple as logging information that human beings can read, as opposed to adapting the information to what the computer wants to work with. A dentist wont know what to do with a stack-trace or “an error occurred executing MySQLQuery1.Execute”. But he or she will understand a log that states – in plain text – “could not store prescription for patient John Doe, the database reports the disk as full. An email has been sent to the administrator“.

You don’t have to be a programmer to replace a disk or move the database to a better location. But the log must make sense. It should just be there, not getting in the way yet easily accessible.

Journaling and big-data

When you are logging every action an oil-pump (and its regulators) do for 24 hours, logfiles can grow into the gigabyte range. Can you imagine one gigabyte of messy, purely technical jargon to wade through when a critical system is down? Well I can, because that’s exactly one of the things I faced 12 years ago when I was hired to “fix” a couple of bugs. A couple of bugs turned into 2 years of re-writing the entire system from scratch. Notepad crashed when it tried to load the original log-files.

The system was all written in Delphi 4, breaking every rule known to object pascal developers even back then. Like services opening forms and forms using DDE to communicate. It was a miracle that it had worked to begin with.

This is where I decided to write a journaling system that would present me, the programmer, with a unified API for writing, reading and even updating log-items stored in multiple files. So you can set a limit to how many log-items one file can contain, and when the log reaches that limit – it create a new file automatically for you. It takes care of everything in the background, keeping track of the files and their content through an index files. This solution helped solve the problem of monster log files. And you know what? That was the core bug in the system. They had used TStringList to load in the text file, append one item, then saved it back out again. Loading almost a gigabyte of raw text while trying to keep up with GPIO signals firing like mad. So yeah, logging does matter!

HexLog naturally implements this, now even faster than before due to Delphi’s dictionary classes and clever use of balanced trees. The best is that the writer mechanism applies to this type of journaling as well. So if you prefer XML thats not a problem, nor JSON, nor RTF for that matter. I’m even throwing in a PDF writer in update 1.

And did I mention both local logging and network logging? And that you can read the logs via a fancy HTML5 dashboard in any browser, both locally and remotely?

Reading more about HexLog

If you find the topic interesting and worthwhile, head over to my company website and read the release statement here: www.quartexcomponents.com. We dont take orders just yet, but it should ship out in the beginning/middle of next month.

And yes, there will be a server edition both for native Delphi and node.js, so there is a lot of value for money in this package.

 

Try out HexLicense in your browser

October 9, 2016 Leave a comment

If you head over to HexLicense.com you will find both the roadmap for 2016 and beyond – but also that you can now testdrive HexLicense in your browser (!) That is pretty cool if I say so myself.

In the browser?

HexLicense "Ironwood" engine under HTML5

HexLicense “Ironwood” engine under HTML5

Hexlicense consists of two parts: the first is the generation process where you mint license numbers. These numbers have some nifty criteria attached to them, like being able to verify that they have indeed been minted using a root-key,  that they evolve and mutate in a non-linear fashion and naturally: they should obfuscate as much as possible.

The second part is the validation process. This is where the customer inputs the serial number he received when he bought your software. Under Delphi you validate such keys inside your Delphi program via the THexLicense component. In the future you will be able to do this via the HexLicense server system as well, which makes is going to make your life as a developer a lot easier.

HexLicense for Smart Mobile Studio covers both aspects, so you can perform the minting and validation. The code is so universal that it will run on your node.js server, in your visual applications – most of the code is actually shared between Delphi and Smart Mobile Studio.

Note: The demo of HexLicense running in your browser is just for educational purposes. It demonstrates that Smart Mobile Studio is capable of some very nifty things. And it also demonstrates the speed and flexibility of HexLicense.

Hexlicense 1.0.1 for VCL is shipping

October 4, 2016 Leave a comment

HexLicense v1.0.1 has now started shipping to customers! And hot on the heels of the VCL implementation comes the FMX version (due shortly).

HexLicense test running on Android [FMX]

HexLicense test running on Android [FMX]

The Android implementation passed all tests yesterday, with the iOS session due for thursday. So hopefully the FMX edition will ship at the beginning of next week.

Head over to www.hexlicense.com and grab your copy while the 40% discount is on!

What up next?

While focus is on finalizing the FMX platform, the server edition is also being worked on.

You will be happy to know that it’s going to be a low-latency websocket client/server solution. This means your products can validate their licenses from HTML5, node.js, Delphi, FPC, C#, C++ or any language that supports ordinary websocket.

Two servers

Two versions of the server is planned: one native win32/64, and one node.js server written in Smart Mobile Studio. The native version uses the ZeosDB library giving you a rich set of options for what database you want to use. By default it uses sqlite which is more than enough for handling <500.000 licenses. However the pro edition will use mysql embedded for maximum performance.

The websocket prototype is already in the making

The websocket prototype is already in the making

The node.js edition enoys the full onslaught of node modules for data storage. Be it clound managed through Amazon or Azure – or a more humble, local sqlite database. You pick what is best for you and your product.

More ciphers, more encryption and more tools! Head over to hexlicense and check it out