Page 1

The Sad State of the European Tech Scene

For the sake of complete transparency, before you start reading this article, you should know the following about me: I am a Swedish citizen. I have lived and worked in Stockholm, Berlin and California. I have also worked remotely for UK-based companies. So the problems I am going to talk about in this article do not stem from some hyped-media BS. They come from having lived and paid the bills in those countries while working in those scenes. And to be completely honest, if I ever get the chance to move back to the US again, I would jump on an airplane right this second.

And now that you know where I stand, let us talk now about the European Tech Scene.

Berlin, Paris, Stockholm as well as many other cities around Europe have been trying for the past decade to compete with Silicon Valley and New York in terms of both product output as well as the overall growth of their domestic tech-scenes. Yet somehow, no matter what, they always seem to lack talent, innovation and the ability to compete on a global level. Even if a company manage to somehow rise and get enough traction and traffic to be considered of a decent size, they are for some reason most often unable to scale globally as fast and as well as American companies can. Here are some stats: link1, link2.

In terms of tech, Silicon Valley alone, including its giants, creates on yearly basis more companies, new tech and profit than what more than half of the European countries combined are able to make in a decade. Which leads me to the question: What is it about the European tech scene that makes it so unable to compete? not only financially but also in terms of innovation and growth.

Let us investigate this further shall we?

I personally believe that this comes down to the cultural differences between the US and Europe. It is a sad thing to say but Europe in general foster a lifestyle that discourages risk-taking. Failure is a big no-no here. We look down on failure and tend to continuously tell our kids not to take too many big risks.
The European dream boils essentially down to having a comfortable lifestyle in an environment where you as a citizen do not need to “risk it all”. On the other hand the American dream is all about living large and taking enough risks in order to one day become more than just an average person.

I can go on and on about the different cultures these continents foster and how the political landscape reflect those dreams perfectly. We could talk for hours about Socialism (or socialistic ideas in general) and why that line of thinking tend to flourish in risk-averse societies. But that would just polarize this article and make things much harder to discuss due to the sheer complexity and the amount of variables that have to be accounted for and talked about.

For that reason, Instead of rendering this into a political argument, let us actually talk about a few practical things that Europe can do in order to better its tech scene:

  1. Fix the relatively low tech wages:

    Take a look at these links: Germany, Sweden, France and the UK. These are all salaries for SENIOR engineers. People who should theoretically be at the top of their profession. Compare that to the salaries of their US counterpart and pretend not to be shocked. It gets even worse if we look at NY or SF – which are the two regions Europe is trying to compete with.

    When talking about the low salaries, there are usually 2 counter arguments that are constantly being made. The first is about the validity of the data. Well, you don’t have to take my word for it, go ahead and google it on your own. Salaries in Europe, especially for seniors, are about 2-3x less than what they are in the US. I personally know of junior developers in the US that make more money than most of the seniors I have hired here in Europe.

    The second counter argument is: salaries only matter in relation to the purchasing power. People tend to look at this and think that the difference in salaries is offset by the high cost of living. But is that really true? Let us see. Software Developer in Stockholm VS. San Fran. I think the answer is pretty clear here. In addition to that, what if we actually took taxes into account as well as the cost of having a family? at that point, there is no competition. San Fran wins 10 out of 10 times. But… If you are still not convinced, how about a different comparison. What if we compared say San Jose to Stockholm? or perhaps Paris to Seattle. It is simply the case that Europe cost too much to live in and pays too little. Even if you compare smaller European cities to smaller US cities you will find that same statement to be true.

    Pay Packet

  2. Taxes:

    The holy grail of the European problem-solving process. If it isn’t working the way we want it to, we TAX IT. I currently enjoy a whopping 40% tax rate while living in Berlin. In Sweden, your income gets taxed at roughly 30% but in addition to that, you have to actually pay an additional 30% for each employee you have. Even if that employee is YOU. Simply put, you have to pay 60% tax to be self-employed (dafuq?). Please keep in mind that this does not include the VAT tax that you have to pay when you consume. Even if you work for a company that pays that last 30% on your behalf, that money is basically taken out of your check.

    Some would argue that this is the cost you have to pay for utilizing the “awesome public healthcare system” as well as many other social safety nets that we currently enjoy and celebrate here in Europe. And while that may or may not be the case (mostly isn’t), leaving the politics of the situation out of this, this system of high taxation actually produces three problems:

    • All the salaries that were presented in section #1 above needs to be adjusted for these taxes. Which means that things just became far more expensive for Europeans than we previously thought. AOUCH!

    • Countries like Sweden, Germany France and even the UK (IIRC) have different tax rates for individuals who are single or married/have children. Which for me begs the following question: why would a single (as in not-married) talented developer stay in any of these countries if he presented with the opportunity to leave? You want talented and smart people in the European tech scene? then stop pushing them away. This is a serious case of Brain Drain. I wonder what would happen in case the US ever decide to eliminate its H1B policy and open the doors for high skilled workers…

    • In order to pay for all these taxes, you now have to charge your clients more money which in turn leads to more expensive services and less demand.

  3. The anti-startup culture:

    Countries like Sweden, Finland and Denmark (Scandinavia in general) are more guilty of this than the rest of Europe. However, even in Germany there is a fair share of “don’t try because you might fail” attitude. Just think about it this way: how can a culture that celebrates this madness ever compete globally? the answer is, IT CAN’T! That culture is doomed to fail in the long run. Ironically enough, the culture of anti-failure is what will ultimately lead to the failure of that culture.


  4. Severe lack of capital:

    There is a severe lack of capital in Europe. It’s not that the capital is not there, because it is. However, the flow of capital restricts the ways in which it might be invested. Taxes and regulations among other things prevent investment from taking place at the same scale as it is in the US. Investing across countries in Europe is much harder than investing across states in the US. Getting funding in Europe is a lot harder than getting funding in the US. Besides, even if you get funded, the expected ROI in relation to the actual capital that you get is not even close to the same.

    A $100 000 investment is basically nothing in the US. The culture of finance is vastly different than in say… Sweden where that $100 000 would translate into 1 000 000 SEK. A million SEK is more than what most can save in total during LIFETIME. The middle class simply lacks the capital to invest while those with capital get to demand more in return because capital is now a scarce resource. The same cannot be said about the US. Not at all…


The sad truth about Europe in general is that we have continuously suppressed human curiosity with Jante Laws and institutionalized education that teaches you to conform to the system no mater how shitty it actually is. We also repeatedly punish failures and allow our successes to escape to better environments because of our lack of support mechanisms. We tax too much and encourage people not to dream big. And the saddest thing of all, we trick ourselves into believing that we can compete.

Huh… if German cars and Swedish furniture cannot compete globally, then we sure as shit not going to be able to compete tech wise.


Validation Baked Into RDBMS? How would that work exactly?

When you develop applications for the web (or software in general), there is one source of information that is always problematic (or at least annoying) to deal with – namely user input.

The Problem:

90% of web-applications are nothing more than a mere CRUD interface between the user and the data storage unit (RDBMS in this case such as MySQL). Once the user enters some data into the application via such things as a login form or a search box, the data is then validated, sanitized and operated upon by the application as well as the RDBMS before outputting some result back to the user. For that reason, most of our applications end up looking something like this:

public function registerUserAction($username, $password){
    if(username is more than 4 characters & alphanumeric & some other requirements...){
        if(password meets requirement 1 & requirement 2 & some other requirements...){
            #do DB insertion in case the username meets the Unique key requirement else return error
    else {
        #output error msg: Username is not 4+ characters or not alphanumeric 

And in its simplest form, a user table schema would look something like this:

  `username` varchar(40) NOT NULL,
  `password` varchar(60) NOT NULL,
  PRIMARY KEY (`username`)

The data entered by the user goes through the sanitation and validation portion of the application and later on gets inserted into the table expressed above. While this process is pretty straight forward and rather easy to do, what we as developers end up having to do is repeating ourselves throughout every project. We add the criteria each field needs to match, a lot of maintenance code around it as well as create display error messages cases based on what and most importantly WHY an insertion failed (ex. username must be 4+ characters). And god, lets not forget having to write tests for all this crap. This process for me is rather tedious and annoying. Thus, I would like to suggest an idea that might change all of that for the better.

Note: and yes, I am aware that in the real world, we use validation classes rather than nesting if statements. But that is essentially the same code spread out over a class instead of having it all rest in the function body.

Please keep in mind that this assumes that validation is only required at the point of insertion.

The Solution:

Sometimes, the validation and sanitation requirements are expressed using regular expressions. Using RegEx allows all those requirements to be captured inside a single if statement. Example:

public function registerUserAction($username, $password){
    if(preg_match("/^[a-z0-9_-]{4,20}$/", $_POST["username"])){

This makes the code shorter and more readable in some cases as well as easier to manage IMO. So the question that I have been asking myself for a while now is: why can’t we insert these RegEx requirements right into the RDBMS as column criteria.
We commonly use Varchar, Int, Text and other data types to determine what goes into each column and how the internal engine should process such data in the future. But given the situation above, wouldn’t it be cool in case we could declare the database schema as follows instead?

  `username` "/^[a-z0-9_-]{4,20}$/" NOT NULL,
  `password` "/^.{4,60}$/" NOT NULL,
  PRIMARY KEY (`username`)

or maybe we could create a completely new engine that runs using a JSON schema

    "user": {
        "username": {
            "rules": ["/^[a-z0-9_-]{4,20}$/"],
            "index": true,
            "unique": true
        "password": {
            "rules": ["/^.{4,60}$/"]

The approach above makes the assumption that all data, regardless of type, is handled as a string. Which makes sense in the context of the web despite what others might say because all HTTP traffic is nothing more than strings being passed around cables from one side of the network to the other. Thus, putting requirements on each column/field in terms of regex right into the schema of the table would enable us to save a whole lot of time when writing applications. How would this help you ask? consider the following:

using the schema above, we can now rewrite the same code as we did at the beginning of the article a little bit differently

public function registerUserAction(){
        $DBinstance->InsertIntoTable("users", $_POST);
    } Catch(Exception $e){
        #outputs error to the user: USERNAME Does Not Match /^[a-z0-9_-]{4,20}$/
        echo $e->getMessage();

Regardless of how many columns, regex requirements or fields you have this will always work. Reason being is that we are passing everything that came in from the client side (using $_POST) straight to the database engine which looks for the fields and validates according to the rules using the schema specified above. So in essence the database engine will be doing something similar to this internally:

foreach($datasetSchema as $field => $properties){
        throw new DataKeyMissing("They Key $field Is Missing!");

    foreach($properties["rules"] as $rule){
        if(preg_match($rule, $_POST[$field]) !== 1)
            throw new DataValueNotAllowed($_POST[$field] . " Does Not Match " . $rule);
    $validFields[$field] = $_POST[$field];
    #After the above steps are done, we can store the data on the harddrive!

what this does is simply loop through the schema and check for the existence of that particular field in $_POST. So if the $_POST["username"] field does not exist, the engine will issue a DataKeyMissing Exception. Using this approach, we can also loop through the regex rules and apply each one to its required column.

If all of this is passed, the data is later on saved using a B+ Tree. Also, prior to insertion, we check the schema requirements in case a unique field exists. We also check for and create hash / linked list indexes for each specified column so that we can have faster data access time. Basically, everything is the same as in a regular RDBMS. The only difference is that we specify EXACTLY using RegEx what we can and cannot enter in each column instead of using some ambiguous data type such as Varchar or Text (once again I know its not really the same thing but from a developer’s perspective, it is).

The Benefits:

  1. Validation is taken care of by the RDBMS layer rather than the application layer.
  2. Flexible schema using regex which means that we can basically force a column to only have a certain type of content that is not native data-type related.
  3. Schema operation rather than data operation: If we wanted for instance to know of all the columns that contain a digit, all we need to do is to look at the schema rather than searching through the entire dataset. In MySQL you have to loop through every row to find in case a Varchar column of data contains any digits. Using this method, we can determine in case such a digit exists just by looking at the enforced RegEx rules.
  4. Performance wise, my guess would be that the this approach could have similar performance outcome as any traditional RDBMS system. Insertion might be more costly due to the regex rules that have to be checked, however, access and read time should not be any different.

Here is how you get me to become your “technical co-founder”

For the past few years I have been getting into the same conversation on weekly basis. Someone contacts me via email/twitter with a message that looks roughly like this one:

Hi my name is X and I am looking for a technical co-founder. I saw on twitter/fb/reddit/whatever that you are an experienced programmer and I thought that I should contact you regarding becoming a technical co-founder for an idea that I have. The idea has the potential of becoming a billion dollar thingy so… If you build it, we can split the profit 50-50. please let me know if you are interested.

xoxoxox – X

All I can think of when I see this kind of email is: “not this shit again!”. So here is a small list of Do(s) and Don’t(s) for when you are looking for a technical co-founder:

1. Introduce yourself
Seriously, introduce yourself. Telling me your name is the least interesting part. I want to know who you are, what you do and why you think we are a good fit to work together. How old are you? do you have any IT-related work-experience at all or are you a complete stranger to technology? This does not have to be a long wall of text. Just make sure to mention something about yourself so that I know who I am talking to.

2. Don’t be afraid to share your idea
This right here is the most frustrating part. Most of you believe that you are actually sitting on the next big thing and want to protect it so bad that you sometime forget that you are looking for a CO-FOUNDER. Your idea means LITERALLY nothing. If your initial trust level is: I don’t want to tell you my idea because I am afraid you might steal it, then why the hell are you contacting me? stop wasting my time. Any programmer worth his salt gets bombarded with ideas and suggestions all the time and yours is not any different. You might believe it to be so but it most likely isn’t. So share your idea with ease and rest assured that even if it gets stolen (which is extremely unlikely), the IT-market is never a zero sum game. The execution of the idea is what matters. Besides, sharing your idea will help you out way more than being secretive every will.

3. Don’t overestimate your idea’s value
For the love of Ra, stop with the “my idea is to build Tinder for penguins –> Tinguins!”. I have no idea why this is happening but for the last 5ish years it seems like the tech market has slowed down. There are barely any good products being made with real world impact. Everyone wants to build the Nth iteration of some social networking thingy that adds no value to anyone. There are literally tens of difference social networking projects launched every day, and ALL of them fail. Occasionally, one of them will get big enough but still no monetization model will ever be found because everything is now given away for free to the end consumer in exchange for some back-end data. What’s the point? The odds are not in your favor, the money is nowhere to be found and the investment is too big compared to the potential returns. I would recommend you watch David H. Hansson’s talk about this subject.

David is the creator of the Ruby on Rails framework and his assessment of this weird money-less idea culture is spot on!

This attitude is not healthy for anyone. If you want a serious technical co-founder to even pay attention to your idea, make sure it counts. Talk to me about a real world problem and your vision toward solving it. Social networking things, dating apps/sites and stuff like that are not interesting and you won’t make any money off of it. Stop wasting your time and most importantly, mine.

4. Don’t overestimate your own value
It infuriates me when I get contacted by someone with the usual 50-50 offer. You know the one… I thought of it, you build it and we split the profit.

You got your idea while taking a shit in a public bathroom. It literally took you 10 mins to come up with this shit (no pun intended). You want me to spend 6 months of my life working on a product for you to split the profit 50-50? what arrogance is this? How about this: I have a TON of good ideas, just like everyone else, why don’t YOU do all the work and we split the profit? the usual answer to that is: “but I don’t know how to program”. Alright then. Enroll in a university, get your CS degree and once your done with that part, start working on my idea and a few years from now we should be able to split the profit 50-50. Sounds fair right? of course NOT. You know why? because the level of investment is not equal. I have spent years of my life learning and working on this stuff so my expertise and your idea are not of equal worth.

Jesus Christ. The reason this gets me worked up is because you fundamentally do not understand the amount of time required to build a product from an idea. That is the ultimate sign of a rookie. If all you have to offer is an idea then why the hell would I EVER partner up with you? There are literally millions of other ideas I can work on so why would I waste my time and give you 50%?

What you need to do instead is to communicate your own value and base your ownership evaluation on that. It is not enough to just have an idea. Do you intend on putting any cash in? do you have any expertise that is essential to the business? Do you perhaps have a law degree and can help the company out somehow? WHAT CAN YOU DO? What is your value?! and please don’t give me any of this “I am the business side” BS. What the hell is that even? Make sure to clarify what your investment will be in comparison to mine before discussing equity.

5. If you have an idea, write a business plan. If you don’t, learn to write one
Writing a business plan is such an underrated skill. When you actually sit down and put everything in writing, what ends up happening is that you get a better understanding of your own idea and how to turn that into a business. If you have an idea and want to present it to me, having a business plan already done would impress me SO MUCH. That stuff gets me wet! That basically means that you have done your homework. You have identified the strength and flaws of your idea and actually put down some work-time in researching things rather than just contacting me with nothing but a shallow hope for a quick buck.

Business plans are most often misunderstood. It is not a marketing document. Don’t try to SELL your idea in your business plan. Instead, your B.P. should identify and describe your idea’s strength and weaknesses. Make some market research and backup your argument with any stats/data that you can find. Be objective and include even the data that does NOT support your idea. Show that there is an honest demand for your product and that the market would like to see it priced at $X. Make some ballpark timeline estimates and put up some goals for your return on investment. You need to do all of that prior to coding not after.

“But, but, but, Where do I get all of this data and do the…” THAT IS YOUR JOB!! All of this is on you, the non-technical one. So if you don’t even do any of this, why would I partner up with you? There is absolutely no reason!

6. Timelines
One of the hardest things to do is to estimate time. Time it takes for the M.V.P. to be done, time it takes to maintain the product weekly, time it takes to get costumer feedback, etc. For that reason, the non-technical co-founder should have a realistic vision prior to seeking a technical co-founder. Basically when you contact a potential technical co-founder, make sure the timeline is communicated properly to begin with. It should look something like this:

The project is envisioned to launch by June next year. That gives us 8 months to work on the product. I have already done all the marketing and research necessary. I even have a landing page setup and a domain bought. I estimate that we will need 6 months of development, 1 month of reiteration and one final month of closed-group alpha testing. If need be, we can launch the M.V.P. by July and have one extra month for bug fixing if that ends up becoming an issue. Marketing will start at month #6 and sign up for beta tests starts at month #7. Our competitors are already established so we don’t need to rush things. We could even extend that time line much further into the future. However, If we launch by June next year, we will be able to display our product at *insert major conference here* and gain a lot of traction. So that is ultimately the goal.

An assessment like this one shows AT LEAST that you have thought things out and even accounted for possible deviations.

7. R.O.I.
If you have made it all the way down here then I hope that you’ve found this somewhat helpful. My final advice would be to make everything about R.O.I. (Return on Investment). That is the holy grail of business. Make sure that ANY investment you make, no matter how small, is worth making. Especially at the startup phase. Basically, it comes down to this: Don’t waste your time doing things that cost more than they give you back in return. In addition, R.O.I. is an extremely important time measurement as well. WHEN can I expect to get a return on my investment? 1 year from now? 5 years from now? and if I invest 6 months of my life, a million dollars, or whatever other asset, what is the realistic and theoretical maximum R.O.I. I can get considering your timeline?

R.O.I. is not just a tool for investors. It is a tool for YOU to make sure that you don’t do anything unnecessary when time and resources matter the most. When looking for a technical co-founder, make sure to communicate when and in what form the expect return on investment will take place. R.O.I. is the one and only true GOD you should follow in business (outside of any moral obligations you might have, etc).

If you are serious about your idea and want to turn it into a business, make sure that you do your part before trying to reach out for any potential technical co-founders. Demonstrate your own value and your idea’s viability. Make yourself useful and provide as many helpful tools for your technical co-founder to work with. Try to invest as much time as possible into the business and don’t let yourself be caught in this 50-50 bullshit. Utilize R.O.I. and have a solid business plan to begin with. Don’t be afraid to share your idea and make sure to create realistic goals. Account for deviations and possible down-time and do your best to make sure that your technical co-founder feels like your are a vital and necessary part of the business.


An Alternative to JSON-LD?

For the past few days, I have been reading up on the underlying concepts behind the Linked Data movement [Wikipedia]. And I gotta tell ya folks, the more I read about it the more I question whether JSON-LD will ever be adopted as a standard by us (the developers).

In this article I will try to describe what I believe a good Linked Data standard should look like. One that could be useful for ME as a developer and business owner to implement. Please keep in mind that these are just a few thoughts that I have had for a while so don’t take my criticism of JSON-LD as an absolute God given truth.

Before I dive into my solution to this problem, allow me to first state the reasons as to why I believe the JSON-LD format is not attractive enough.

1. Verbose Integration:
The main goal/requirement for JSON-LD was ease of integration. The idea here was that we (the developers) would be able to transform our JSON data into JSON-LD without much effort. And boy did this standard not reach that goal. The standard actually makes it harder for us to migrate our existing APIs into a standardized form. Consider the following:

Our API Endpoint: GET

Currently produces something like:

    "eventID": "10105124",
    "summary": "Lady Gaga Concert",
    "location": "New Orleans Arena, New Orleans, Louisiana, USA",
    "start" : "2015-04-09 12:00"

If I wanted to migrate this event data into JSON-LD, I have to restructure my JSON so that it looks like the following:

  "@context": {
    "ical": "",
    "xsd": "",
    "ical:dtstart": {
      "@type": "xsd:dateTime"
  "ical:summary": "Lady Gaga Concert",
  "ical:location": "New Orleans Arena, New Orleans, Louisiana, USA",
  "ical:dtstart": "2011-04-09T20:00Z"

//This sample was taken from:

Now, I don’t know about you but for me this syntax gives me a headache. Not only did we abstract a lot of the information into the @context inner object, but we also changed the naming and the way the columns behave. This is NOT, by any stretch of the imagination, what I would call easy integration. Even with the usage of something like Fractal, we would end up breaking the API clients our users have built. Our only option here is to issue a new version of the API with these changes in place. Even if renaming the columns was not a necessity (which it actually isn’t according to the JSON-LD spec) what will end up happening is that all our API clients AND API documentation needs to be rewritten to describe the changes in the schema.

Edit – Just to clarify: your JSON payload key-value pair do not need to change. Another implementation method would be to have everything related to the schema in the @context object. It is essentially the same thing. The only difference is where the verbosity is expressed – In the actual key or the @context object.

2. Payload:
The verbose nature of JSON-LD makes it extremely unattractive for high payload APIs (I would argue). Just take a look at some of the simple examples here and see how an object containing a few key – value pairs ends up containing more information about the object than the actual content it serves. Now, I am not saying that this is wrong. My concern here is that as your service gets bigger and your endpoints start delivering more complex nested data, this could become a hassle. And yes, I know that nested data is not the best approach. But sometimes it is far better than having to deal with multiple requests. The standard’s syntax should not become a big hurdle and prevent the developer from doing something that he knows is in the best interest of his application.

3. Benefits:
What exactly do I get by having to go through the hassle of implementing JSON-LD? honestly, I cannot think of a single short-term benefit. The benefits of linked data that I can see emerges when the entirety of the network uses the same standard. At that point, it becomes attractive for me to use the same standard in order to be able to take advantage of other providers data-sets with a common structure/format. However, this becomes a case of catch 22. Everyone needs to be connected in order for us to benefit yet no one will connect until everyone else is connected. The only short-term winners in this scenario are search engines. They get to categorize and map your data in relation to the network’s (provided you allow them to crawl it).

I might be wrong about all of this though. My main concern is that it is NOT feasible for most of us and our employers to go through the hassle of implementing this. So, with that in mind, I would like to suggest that we tackle this problem a bit differently.

First off I would start by creating something similar to But rather than listing packages, we would list namespaces of pre-defined JSON components. This would be in a sense similar to the way JSON-LD currently does things. However, we need to add a twist to it. For the sake of illustration, lets call our JSON component manager for
JSONPAC would start with a bunch of predefined simple components that looks like the following:

std/user -->
    id : STRING | REQ
    email : STRING | REQ
    password : STRING | OPT
    reg_date : DATETIME | OPT

std/event -->
    id: STRING | REQ
    title : STRING | REQ
    location : STRING | REQ 
    start : DATETIME | REQ
    sponsor : []std/user | OPT


The std namespace would have a ton of these starting objects that reflect the basic set of objects any API might return to its user. In order to understand how this differs from the JSON-LD approach, lets look at the following example:

Bob owns an API with the endpoint: GET Bob’s response, after implementing this standard, could then look like this:

    "@namespace" : "std/event",
    "id": "123123",
    "title": "Lady Gaga Concert",
    "location": "New Orleans Arena, New Orleans, Louisiana, USA",
    "start" : "2015-04-09 12:00"

Meanwhile, Alice owns a different API with the following endpoint: GET Alice’s response could then look like this:

    "@namespace" : "std/event",
    "id": "111222",
    "title": "John Mayer in RIO",
    "location": "Somewhere in Canada",
    "start" : "2015-04-19 12:00",
    "sponsor" : [
            "id" : 13584,
            "email" : "",
            "reg_date": "2011-01-01"
            "id" : 471548,
            "email" : ""

Notice how Bob’s API has no sponsor field in his response because the sponsor field in JSONPAC std/event is OPTional. Meanwhile, Alice’s API uses an array of sponsors each of which have the @namespace std/user implicitly defined in the JSONPAC schema. If Alice tries to embedd something else into the sponsor field other than what is allowed in the JSONPAC std/event --> sponsor manifest, she should get an error. This way, we enforce the that the integrity of the data goes hand in hand with the standardized schema that is set for us by JSONPAC.

Your question now is: but waaaaaaaaaait a minute. What if Alice wants to return her own type of sponsor that isn’t the same as the []std/user schema? Well my answer to that would be Extend and Override. You simply create your own namespace at JSONPAC and extend the std/event object and override whatever you want. Thus the JSONPAC library would look like the following:

std/user -->
    id : STRING | INT | REQ
    email : STRING | REQ
    password : STRING | OPT
    reg_date : DATETIME | OPT

std/event -->
    id: STRING | INT | REQ
    title : STRING | REQ
    location : STRING | LONG-LAT | REQ 
    start : DATETIME | REQ
    sponsor : STRING | []std/user | OPT


alice/event --> std/event
    sponsor : []alice/sponsor

alice/sponsor -->
   id : STRING | REQ
   name : STRING | REQ

After creating her own namespace at JSONPAC, Alice can now return the following JSON result:

    "@namespace" : "alice/event",
    "id": "111222",
    "title": "John Mayer in RIO",
    "location": "Somewhere in Canada",
    "start" : "2015-04-19 12:00",
    "sponsor" : [
            "id" : "userID1",
            "name" : "Dan Gilbert"
            "id" : "userID2",
            "name" : "Dan Gilbert The Second"

As you can see, we extend and override namespacing. This way JSONPAC can handle all linked data relationships in one place. However, there is ONE problem with this approach. What if the developer gives the wrong @namespace or forgets to include it for whatever reason? What happens then? Well, my suggestion would be to write a tiny little test-executable that handles this. Once you are done building your API response you run the tool from your terminal using:


The tool gets the JSON result from the url, validates it against the provided namespacing from JSONPAC. If all goes well, the tool will display a success message, else the tool will provide the developer with the row/place where the error occurs. The tool should even recursively go through the sponsor[] array and see if each object matches alice/sponsor (the provided namespace) in its content. What this would do is add another layer of testing – namely output testing. If the validation test passes, then you guarantee your data-structure’s integrity and provide a way for all your API users to lookup your objects using JSONPAC. All you need to do in your documentation is write the following: Endpoint X returns alice/event. Notice how this entire testing process needed only 1 line: @namespace : "alice/event".

The front-end developer implementing your API can also download the JSONPAC-TOOL and verify your data’s integrity. This way any developer would know for sure in case an API is reliable or not. In addition, the JSONPAC-TOOL could also implement some cool and much needed functionality such as:

JSONPAC-TOOL extract alice/sponsor

This command could for instance loop through the entire result set from the endpoint and extract all alice/sponsor objects and give them to the user of the tool. I can go on and on about what features could be implemented but the main point is this:

This approach gives us easier integration, centralized management, data-structure integrity testing, output reliability, built in data-extraction capability, extensiblity, and much more. In addition to all of that, the data structures are all linked in one central place with very non-verbose syntax.


CRON Error Notifications in Real Time

This ScriptCheck package available on Github.

If you have ever worked with CRON jobs that involve getting and parsing data from 3rd party APIs/feeds, you will understand me more than anyone else when I say: handling CRON-related Errors and Exceptions suck. It is inevitable that your script will fail at some point in the future for one of many reason. In my particular case, one of the data providers that I use tends to fail on me. Once my CRON script tries to parse what it perceives to be the retrieved data, an Exception (or an Error) is thrown.

Out of the box LAMP stack offers us two different ways to deal with these unexpected errors:

  1. File Logging: Have PHP log the error into a file that you later on have to check/review manually.
  2. CRON Email: LAMP can also utilize the CRON Email functionality to send you or the server administrator an email regarding the Error incident and what caused it.

Unfortunately, these two solutions are rather limiting. What if you want an external API to be notified upon script failure? or perhaps have a record inserted into a SQL DB table with all the possible Error info? these options are currently not available and for that reason I wrote a little library called ScriptCheck.

ScriptCheck is a simple package that allows you to specify a notification method by registering a handler prior to the script’s execution. At the start of the application, ScriptCheck will register itself as the default PHP error handler via set_error_handler and set_exception_handler. Afterwards, the script will continue executing as usual. If an error occurs, the error handler will catch that and notify all handlers/observers.

Sample code:

//Use composer autoloader or your own!
require 'vendor/autoload.php';

use Lorenum\ScriptCheck\ScriptCheck;
use Lorenum\ScriptCheck\Handlers\FileLoggerHandler;

//Instanciate ScriptCheck and add a fileLoggerHandler to be notified
$sc = new ScriptCheck();
$sc->addHandler(new FileLoggerHandler("test.log"));

//You application logic goes below here!
throw new Exception("Test Exception");

As of right now, ScriptCheck allows for 4 different types of handlers to be registered:

  1. FileLoggerHandler: Log the error into a file, similar to the standard LAMP stack error logger.
  2. SQLDBHandler: Insert the error as a row into a SQL DB.
  3. EmailHandler: Emails the registered person all error details.
  4. APICallHandler: Calls an external API via POST or GET.

You can actually combine as many of these as you want. You can also extend any of them or implement your own by using the HandlerInterface interface.

More information about this package can be found in the Readme file at Github.



Hello World!


echo "Hello World";


As a first post on this blog, I cannot find anything more suiting to write than “Hello World!”.

This blog marks the start of a new chapter in my career as a programmer. I intend on having this blog become a creative outlet for me where I get to display some of my work, discuss new ideas/concepts and hopefully create an entertaining and educational environment for beginner programmers to enjoy!


This is going to be fun :)