Page 1
Standard

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).

Conclusion
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.

Standard

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 https://someservice.com/event/10105124

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": "http://www.w3.org/2002/12/cal/ical#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "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: http://json-ld.org/playground/index.html

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 Packagist.org. 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.org.
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 https://bobservice.com/event/123123. 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 https://aliceservice.com/event/111222. 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" : "somedude@asd.com",
            "reg_date": "2011-01-01"
        },
        {
            "id" : 471548,
            "email" : "anotheruser@asd.com"
        }
    ]
}

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:

JSONPAC-TOOL validate https://aliceservice.com/event/111222

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 https://aliceservice.com/event/111222 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.

Standard

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"));
$sc->register();

//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.

Cheers

Standard

Hello World!


<?php

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 :)

 

Cheers!