Archive

Web Development

Following are my impressions and thoughts inspired by the “AR in Action” conference at MIT’s media lab to which I was kindly invited to this week by John Werner.
Augmented Reality” is the notion of adding an additional layer of data to our perceived reality. The most popular example for AR, as far as I could tell is Pokemon Go in which the character appear as in our real environment, but as the game was referred to several times during the conference, it is not a real AR since it doesn’t truly interact with the environment, rather than merely use it as a background to present its characters. But this is general idea – have some spectacles or a window (such as tablet) from which one can look at hers or his environment and get more information.
An interesting thought was proposed by Christopher Croteau from Intel that augmentation mustn’t necessarily be visual. It can also be audio – for example a running app that provides you audial coaching is actually augmenting to your running experience. A background music can also be considered as augmentation.
AR’s biggest advantage over VR or the standard way of consuming data is lack of need to disconnect from the presence. Along comes the famous photo of our generation, completely immersed in our mobile devices. completely disconnected from the “now”.
This made me wonder why is it so important to be in the “now”. “now” can be boring (especially now, as I sit in the airport waiting for my flight back home). True, mobile disconnect us for the immediate surrounding people, but then again – what’s wrong with that? Calm down with your “heretic!” calls, I would personally rather talk with someone I care about than someone who just happened to sit next to me, and I’m pretty sure it’s to the preferred choice of all parties involved. If someone prefers his virtual friends over your presence – I guess you’re just not interesting enough. I don’t really think that but I think it’s a thought worth exploring. but how AR can make this better? after all, I will still use technology to talk to my virtual friends and not the present next to me. The only difference will be that I will stare into nothingness like a weirdo instead of a screen.
The conference had plenty of speakers. More than a 100, according to the publications. Some of them preached to the choir about the wonderful potential of AR; others showed their work whether it was related to AR or not (some even without even trying to conceal the fact it’s completely unrelated. I should mention that it doesn’t mean their talks were bad, just unrelated). But from what I gathered, AR has three usages nowadays: (i) Show designs (e.g. architecture‘s work); (ii) provide instructions; and (iii) be cool. Being cool – such as provide 3D Pop-up to QR-code. It’s cool. it’s great advertisement. But being cool is something that has to be unique and it’ll become over-used and boring incredibly fast.
As the AR field is still emerging, the conference was also about VR, which is actually easier to implement, as you don’t need to understand the real environment in which the user is present. But VR has a huge disadvantage – it completely disconnect you from the surrounding. As one of the speaker came to the stage with a holo-sense on, I felt that he’s not really there, and didn’t really see a reason to be “there” as well. I think it has a lot to do with the emotional expression we provide using our eyes and eyebrows and once this is covered – we will just lose our audience.
Robert Scoble spoke about the “beautiful potential” of AR and how it will change our future. He pointed out three scenarios – mall-shopping, hotels and drivings. Personally, by the time AR will actually be useful, automated cars should take over (and every day that passes by and people die in car accidents is a disgrace to humanity). I’m not exactly sure what would he change in his hotel experience but the mall-shopping example bothered me. Especially as I don’t go to malls and I think that “look how much money many can be made of this” is an incredibly bad driver for innovation. It may be efficient but it’s still bad nonetheless.
There were few interesting demos of really useful AR in use for instructions and tutorials. But it reminded me of the story about NASA’s 10m$ investment to invent a pen that can write in zero gravity while the soviets simply used a pencil. It’s ok to experiment with the technology even when it’s not efficient but in order to solve real-world solution, its advantages compared to a low-tech solutions don’t necessarily have enough ROI.
Christopher Grayson suggested using AR to remember names (essentially by providing them digital “name” tags) made me think about the right to stay anonymous. This, should be mentioned one of the important reasons google glass failed. It’s true that I walked in the conference with my name tag on but this is actually an incredibly inefficient technique as it requires the reader to stand in front of me and make sure the tag isn’t flipped over (as it usually does) or covered by my jacket. Most like I’ll know that s/he’s taking interest of me and I would feel less susceptible to scams by a stranger who knows too much about me.
He took pride in having more than 2000 friends on Linkedin, while socially-speaking, we’re able to maintain only up to 1500 friends. I think it requires a redefinition for the word “friend” as it raises the question of the type of relationship one keep with his closest thousand of friends.
A word on technicalities. There were a few talks that were… ill-prepared. Whether it was the technology failing to display the presentation or demo on the big screen, or speaker who clearly didn’t prepare their talk and just rumbled on. Worse were those who weren’t even interested or at least funny. Rightfully said, it was mentioned by the organizers that future conference they’ll “audition” the speakers, so I’m optimistic on that regard.
I didn’t attend any panels but one, which I happened to stumble by as I was waiting for the following talk. This panel was about “Future of AR” and each panelist in his own words said, to my dismay, that the future cannot be predicted. They later continued to rumble but for me the picture was clear that the future is hazy. Personally I think the future of AR lies with an incredible smart AI and image recognition and processing. It will then be able to whisper useful information to help you make conscious decisions. In its evolution AR must and I cannot emphasize enough how critical it is – MUST get rid of the clunky VR goggles, it will never work with them. The alternative should be either the use of normal plain glasses and which the user’s pupils are still visible or at contact lenses that provide this information. Yes, we have a lot way to go, but that’s the future AR should aspire to.
A few honorable mentions: Bob Metclafe (the guy who invented Ethernet) and Dan Bricklin (the guy who invented digital spreadsheets), who didn’t actually talk about AR but are incredibly smart and entertaining; Gordon Bing from EA who showed how AR can be inspired by computer games; And last but not least, the guys from PTC that gave a few demos of AR that actually work efficiently.

TL;DR, My first thought about ES6 was “but you’re just making things worse!”. I think the thumb-rule for improving a language will it be easier to learn it and not more difficult, and clearly that’s not gonna happen when you keep adding more arbitrary tools to do the same things but slightly differently (best example for this is for…of which iterate over object’s iterable elements, as oppose to for…in which iterates over all of the object’s elements.

To cut things short – JS is missing official versioning, that will allow it to purge bad code. It actually does have some  versioning, because when you add a new feature it does mean that an older browser won’t support your code and additionally, we already have “use strict”; which is actually versioning. So instead of ‘use strict’, we’ll have ‘use es6’ and everyone know how to handle it. We can later think of backward-computability to weird folks who still use IE6 by trans-piling and stuff. That’s a different story and isn’t that complicated, especially as I’m aiming mainly to clean to language and less on adding new features.

So looking at First steps with ECMAScript 6, I compiled my own remarks/suggestions of how I believe things should be done:

1. Scoping: var, let, const, IIFE and blocks

Originally {…} was suppose to be a block that contains privately-own local variable. JS screwed this up by keeping the variable to the use of the external function. I’m not sure why, but now they try to patch it up by using ‘let’. So let’s make it much more simple – {…} has its own variables that die as soon as the block ends, unless they’re being used by an internal block that outlives the original block. This is how to should have been to being with. Fixing is better than patching.

Const” my be a nice concept but when talking about pointers, which we do in 99% of the time, it’s actually meaningless.

2. Template literals = `hello ${name}!`

It’s a nice feature, but to be honest, is it really critical to be a core part of the language? I agree that the ability to write multi-line string can be incredibly useful. if we could only enforce having semi-colons at the end of commands, are code will become much more concise and everyone should know that line breaks means nothing to the compiler. And again, I don’t think template-engines are wrong – I just don’t think they should be part of a core language. Keeping them as a separate library will allow them to evolve independently. Why evolve? because we might want conditionals, loops, sub-templates and millions other things. why limit it?

3. Arrow function

Array functions are less readable. don’t. just don’t.

4. Multiple return values

Functions return a single value. It’s a mathematical thing. This single value might contain an array, or a set of values. We might want to be able to easily parse to values (talk about splat in a second), but the bottom line is that function return a single value. Trying to return weird things like { obj1, obj2 } which is actually an abbreviation of { obj1: obj1, obj2: obj2 } create syntax anomalies which in turn makes the code less readable.

reduce the anomalies! stop adding more of them! On a side note, I never really understood why typeof and instanceof cannot be simply treated as functions. or why the are different from one another. inconsistencies is what makes any language dreadful. This is something I would have like fixed.

5. For (;;) => For (…in…) => forEach(function) => for (…of…)

So For…of is just like For…on, only it’s more useful as it actually return the iterable elements of an object and not all its elements (which might include functions, for example). we’re having a zillion of loop and iterations that one cannot deny that this is a money-pit and there’s never going to be a solution that makes everyone happy. And that’s ok – but why incorporate ALL the solutions in the language? it only makes it more complicated.

why can’t we simply say that object has an iterables property, returning an array of its iterables so “for (key,value in Object.iterables(map)) {}” would iterate over ONLY the relevant items and in each iteration key will be index and value will be the iterable object itself. there. problem solved without adding a new command.

We already have Object.keys, so it shouldn’t be a problem to add Object.values and Object.iterables.

6. Parameters default values

Avoiding the need to handle default values within the code is very nice, but it leaves the devil an opportunity to introduce hell when my default value is actually a function that runs… when?

This is one complexity I think we should avoid.

7. Splat, Spread, Splat and Handling named parameters

We’d like a feature that says – “hey, all these values should actually be part of an array” and vice versa – “hey, this object is actually is a bunch of separate variables”

Here comes splat – “” which is an ok idea. so why can’t we simply have the other way around


  function myFunc (...numbers) {

  return number[2];

}

myFunc (1,2,3); // return 3
function myFunc (values..., ...other) {

  return (first + second + other[2]);

}
myFunction ({first:1, second:2}, 3,4,5) // return 8

in my example “values” doesn’t exists anywhere – it’s created and immediately breaks apart to it sub-elements.

In the current proposal “…” is actually used for both scenarios – either to collect variables and to spread them. I suggest the position will hint it action – …collect, spread… making it much more readable

It’s worth mentioning that whenever you invent a new element in a language someone is very likely to use it in a way you didn’t expect. For example, what will happen if I write source…target. well, you guessed it, it will break source to different elements and recollect back them to target.

8. Method definitions instead of function expressions in object literals to

the ability to write var obj = { myFunction () { … } } is pure laziness and breaks the consistency of the code. That’s bad.

9. Classes and Class extends

There’s ruling paradigm called “object oriented”. But javascript isn’t about it. JS is about manipulating JSON objects. JS is perfectly fine without classes. stop forcing it into something it’s not. All JS apps start small and fast but as soon as they become robust, they also become incredibly slow. So, people, please trying to make complicated JS. you’re killing our web!

Prototypical development means that whenever I get a JSON from the server I can easily apply function unto it – cat.prototype = catBehaviour. so now the cat JSON I got can cat.meow(). I don’t really need to create a new object for that. why do you insist to make thing more complicated?

I agree that the current prototype mechanism is slightly too complex but why not simply fix it?

10. From objects to Maps

Javascript’s Object suffers from having string keys. not only that but there’s an escape issue with them. so ES6 introduces a new element type just to solve the escaping issue. seriously? I’ve never bothered with that. If you go ahead and fix that (and not clear why not update the existing object) – why not have the keys as any object (you can flatten with JSON.stringify internally if you want)

11. New String and Array functions

Yes, with ES6 you can now have string.startsWith(). but, seriously who care?

you do realise that because you now decided to use this stupid function, you’ll no longer support ES5-only browsers, right?

and maybe this is what it really comes down to – Languages should have extremely long cycles – let’s say update a language every 5 years if not more, in order to give it time to propagate everywhere. Javascript is the most important language de-facto in the world today not because it’s a great language, rather than because everyone uses it. If you make it into something that not everyone uses – they’ll just keep using ES5. All those small nice-to-have function should be on external layer, or framework. Let’s call the language coreJS, and this will be scaffoldJS, and this can be easily updated, let’s say every 2 years. On top of that we can have libraries that every developer decided which to use – a reasonable update time for this should be 6 months.

js-core should be super-stable, super-consistent with itself, super-reliable, super-simple (and not super-easy) and super-fast. once we can have that, we can start talking about the external layers or silly features like startsWith or arrow functions.

Passwords are troublesome. I can tell they’re troublesome because most website have the “Lost your password?” button readily available. Because password tends to be lost, or forgotten, or entered via keyboard with different layout (Try using the “£” symbol and good luck to all american-keyboards users).

Passwords are crackable, as majority of people don’t understand the likelihood of someone trying to break down their password. So to make the life of hackers slightly more difficult we now have the CAPTCHA mechanism, that aside from being already cracked by hackers is simply annoying. In fact, the “Lost your password?” is annoying too – you might as well call it “Annoyed? Click here”. Think of it this way – the user clicking this button is only one step away from not using the service.

And funny enough – this button is actually the solution to our problem. When you click button a two-steps authentication is initiated – usually via email which includes an unbreakable code that allows to update your password. Well, why just change password? Why shouldn’t it allow access to all the service?

With this reasoning, once you can you edit the password – the service is practically accessible and should therefore be so!

So instead of asking the user for his username (which is usually an email anyhow) and password – why not simply asking for the email?

So here’s the entire procedure

  • user open service, type in his email, click submit
  • A special token with time of creation and the user’s IP is created and sent to the user’s email
  • User click the link in his email
  • Token is sent back to the server and is verified that the IP matches and token hasn’t yet expired (let’s say one hour from token creation time)
  • A new token is created with user-id and user’s IP and sent to the user, encrypted
  • The user cannot decrypt this token but whenever he communicate with the server he passes this token along to authenticate himself

The browser should keep the authentication token for a reasonable time – let’s say 3-6 months, during which the user won’t have to go through this process again. This cookie should not and cannot be simply copied to another machine as it require the computer to have the same IP. And if you’re truly concerned with security, the service can ask the user for his public PGP key along with his mail and thus send him an encrypted mail only he can decrypt.

The only problem with the mechanism that I found is that it requires your user to temporarily leave the service and check his email. How many users will you loose because they forgot to return and how many will you loose because the password was just another hassle they didn’t care to handle?

Some might say javascript encourages nesting, for example;

var greetDeeplyCurried = function(greeting) {
  return function(separator) {
    return function(emphasis) {
      return function(name) {
        console.log(greeting + separator + name + emphasis);
      };
    };
  };
};

Personally, I don’t like anonymous functions. They make it harder to debug. If you do use an anonymous function, please still give it a name. note the for

var bar = function () {…}

, the function is still anonymous. You should either write

var foo = function foo () {}

or

function foo (){}; var bar = foo;
  1. I don’t like creating function inside other functions, since I don’t know how many time the wrapping function will be called. Simply define two function and let the wrapping called the internal.

Nesting function is the lazy-solution to handle Javascript’s scope issue, as function don’t really hold a scope on their own one might find it easier to have all the scope nestled together so for sure you’d know, which scope is being used.

I would resolve that using bind, call and apply to determine the specific scope I would like my function to run. Generally I would avoid outside-the-function scope variables – each function should use only what is passed into it, and with the use of bind you can send parameters from different sources: in this example

myButton.onclick = foo.bind({},myVariable)

myButtons will have two parameters – myVariable and the onClickEvent, both coming from different sources.

That’s being said, My server-side has a lot of sequential asynchronous operations – load a topic and use its data to load the community and the member and then makes changes, write them and send the result to the client side.

I suggest a Sargent to manage our tasks on our behalf.

sergeant({ topic: { table: db.topic,
                         data: userNewTopic,
                         after: sergeant.validate }, 
           member: { table: membership,
                     load:{ userId: authUser.id }, 
                     before:getTopicCommunityId,
                     after: sergeant.isSuccess } ,
           savedTopic: { table: db.topic, 
                         before:prepareForSaving,
                         after: sergeant.isSuccess },
           finalize: { json:true }},
           “topic,member,savedTopic, finalize”,  callback);

or

sergeant({ map of tasks },
           [ordered list of task name], methodToRunWhenDone);

A task has the following properties

  • table – a node-ORM object
  • load – either a object-id value or a node-ROM compliant map of properties
  • multiple – if the object exists, load will assume multiple results. Multiple can be a node-ROM compliant list of properties such as order, limit, order, and groupBy
  • data – data placeholder to be passed on or used by save
  • save – boolean flag. When save=true, data will be saved. The repository[taskName] will then store the save operation output.
  • before – function to be called before commencing the task’s main operation.
  • after -function to be called once the task’s main operation is completed
  • json – will run toJSON() function on items in the repository

before/after functions may return the following values

  • true/ undefined – continue operation as normal
  • false – the main operation will be skipped or discarded. If before return false, after will not  run as well
  • Error – sergeant will stop its operation and call methodToRunWhenDown(error)

load overrides data (so data acts as default value until load is pre-populated)

A Task with load but save=true will throw an error  before any task starts.

[ordered list of task name] can either be an array of tasks-names or a comma-separated string.

The before and after functions’ parameters are (repository, taskMap, currentTaskName)

json runs after the main operation but before post. Its value can be one of the following

  • true – will json-convert the entire repository
  • [] – (empty array) will json-convert only the current task result. if there’s no data or load properties for the task it will exit before running
  • [taskNames] (array of strings or comma-separated string) – will json-convert the specific tasks output. json is agnostic whether the task have run or not
  • undefined/false – won’t try to json-convert

 

If repository[taskName] is an array, json returns an array of objects, each was json-converted.

A good practice will be to run post the last json and delete any unnecessary temporary repository elements.

so in conclusion, Sergeant.js is used to run a list of db-related tasks (which seems to apply to most of my server-side methods) in a sequential order, thus saving the need to nest your operations in an unreadable fashion.

After an exceedingly long break, I’m back working on Thedorus, so here’s a rather technical bit on what I’m currently doing.

As I’ve mentioned in the past, I don’t like Angular. My distaste for it and alike comes from their heresy of writing javascript code within the html code. I think it’s an incredibly wrong idea as it bind the code to a specific HTML, it duplicates code maintenance in case you have several HTML versions (themes for example) and it make the work of the HTML coder (assuming it’s not the JS-programmer himself) much more difficult as he needs to edit the HTML without stepping on any mine.

My alternative comes in two steps. First, I have my template-engine – O.
It’s works like mustache.js, only it serves my needs – it can easily use sub-templates and it has iterations, conditionals and even translation-support.
So running my engine would produces me a beautiful page, but I still need to integrate the JS-code somehow, right?
So my second step is to identify all the elements in the HTML that requires binding. I’ve marked them with the css-class “js-registry” and if they don’t have and ID they would also require the attribute “data-register” with the corresponding registry code (explained in a second).
But I said “no messing with the HTML”, right? well, I lied, but let’s go through this. An HTML element has 3 attribute that can be used as an identifier – the tag name, the element id and CSS class.
The tag (e.g. “<ol>” for ordered-list or “<u>” for unordered-list) should not be referred by either CSS or JS as we never know when it might change. CSS classes are obviously used for CSS. I should mention I despise people who use css-classes such as “text-align-center”. I mean, seriously? if you’re deciding the style at the HTML level why not use <center> tag and get it over with? CSS classes should not be indicative of the style content rather than the style function (e.g. “message-title” or “sign-up-button”)
Element-IDs, which are unique per page are for the sole use of JS and it’s a great way to find elements. But in the case you have a list of generic items (a list of message for example) that needs to be referred from the JS, then (and only then) I find it acceptable to use css-classes in the JS. But to make it clear for the HTML-coder that these classes are for the use of the JS (and he might end up losing a finger if he dare to temper with them), we can add the prefix “js-“, so in our example we’ll have “js-register”.
my code has a singleton “registry” code that contains the functions to be applied on the different DOM elements. So let’s say I have a DOM element with the ID “messageList”. If I’ll try to register it, I’ll find the pre-stored function that would fetch me the list using AJAX and then place them in the DOM document. Once messageList is registered, I would also look for any descendants and thus I’ll find myself registering all the messages as well.
I should mention that when registering the descendants, I’ll only registered this whose CSS-display style attribute isn’t set to ‘none’. That way, I won’t fetch any unnecessary information which I might not need. However when resizing the window, I’ll be sure to look again for elements that haven’t yet been registered. This functionality means that small-screen mobile won’t be bothered with loading elements they don’t need.
Using this registry system save me the need to be constantly vigilance for the case a button appears on the screen – meaning, I don’t need watchers, which are much-dreaded performance killers.
So I’m ok with intervening with the html and writing the “js-register” CSS-class name but bare in mind that this isn’t really a code, rather than a simple placeholder for code and it doesn’t affect the readability of the HTML code.
    this.onElementRegistered = (function onElementRegistered (elmId) {
        if (elmId !== undefined) {
            this.registerS(O.ELM.per('#'+elmId+' .js-register'));
        }
    }).bind(this);
    this.registerS = (function registerS (subElements) {
        var elmCount = subElements.length;
        while (elmCount--) {
            var dElm = subElements[elmCount];
            if (dElm.style.display !== 'none') {
                this.register(dElm);
            }
        }
    }).bind(this);
    this.register = (function register (dElm) {
        var dElmId = dElm.id;
        dElm.setAttribute('class',dElm.getAttribute('class').replace(/\bjs-register\b/,'js-registering'));
        var registerCode = dElm.getAttribute('data-register') || dElmId;
        if (this.registry[registerCode]) {
            this.registry[registerCode](dElm, this.onElementRegistered.bind(this,dElmId));
        }
        dElm.setAttribute('class',dElm.getAttribute('class').replace(/\bjs-registering\b/,'js-registered'));
    }).bind(this);
    this.onWindowResize = (function onWindowResize() {
        this.registerS(O.ELM.per('.js-register'));
    }).bind(this);
    window.onresize = O.EVT.subscribe('window.resize',this.onWindowResize).getDispatcher('window.resize');

Up until now, the getMainPage function, which was part of the topicProcess made internal invocation to get the user data and the tags and put it all together to create the page’s data before it was return to the WebApplication to be rendered into XSLT and then HTML. I decided that TopicProcess shouldn’t know nor care about the tags and user info, and I can actually put into use the plugins mechanism which didn’t do anything yet.

How is a plugin work? well, after identifying the call, the WebApplication prepares a list of all relevant plugins, which are methods, much like the handlers we had until now and runs all the plugins in a recursive manner:

  • a plugin get the input,
  • may alter it,
  • if there’s another plugin in queue, runs the next one
  • if not, it runs the handler (i.e. main application), which returns a JSON object as output
  • the plugin may alter the output and return the call to its caller
  • so we end up back in the WebApplication after all plugins and the handler went over the input and the output

TagProcess now knows that whenever the url “/” is called, it should run the pGetTags plugin (the prefix “p” is for plugin, as the function is slightly different the getTags handler). It was extremely easy and it works like a charm.

The next step, which I will do sometime in the future is more challenging: currently, the XSLT knows nothing about the plugins and their additions to the page. If future plugins should be available for anyone to add – the XSLT shouldn’t know about the plugins either. At most, it should know it should run a plugin-XSLT that will create an HTML snippet with an attribute stating where the snippet should be placed (e.g. “inside-sidebar”). But who will do the actual placing? can I trust the server-side code to do it effectively? nothing like a good challenge to call it a night 😉

so I’ve bunched-up some updates, some are extremely cool, other are still very interesting.

First, I’ve wrote a mysqlDbBuilder that will check if the DB exists and all tables are up to date and if not, it will build and update whatever is necessary. I still didn’t have any updates but it should work and it’s very cool.

Second, I added xslt-support for plugins. how does it work? in the plugins folder there’s an “include” folder that should list all available plugins (at least the ones we’d like to have XSLT support); there’s a single place where all plugin-output content is written in the page, called (naturally) “#plugins”. After creating the HTML, I use Cheerio for DOM-manipulation to move the different items to their rightful places using their css classes that look like “reposition-after-sidebar”, meaning that the element should be the next sibling after the #sidebar element. elements can be before, after, prepend or append (added inside the element at the beginning or the end). so that’s works. it’s very cool, but not yet supported by client-side, as there’s no real need for that now.

I still haven’t finished with plugins as the database doesn’t support them. The existing mysqldb and even mysqldbapi shouldn’t be aware of the plugin-model. On the other hand, the plugin shouldn’t be aware of the db’s internal (the fact that it is mysql for that matter). I’m thinking about using ORM for this, although I don’t like this concept as it limits the power of the DB (can’t limit string length, for example), but honestly I’m not sure of any other way. Another issue would be the initializing of the plugin-db-tables, as again, I’m not allowed to intervene with the system’s sql-instructions file.

My next task was to add an English version to Theodorus. Presumably it should be too difficult, I translated all the strings and changed directions of the CSS. So it’s all good, but now comes the question “What should be the default language?” (language is determined by default theme) and I’d be happy to agree it should be English. However, Theodorus works in Hebrew, and I’d like to keep that. No problem, just move the theme selection from the config file to the database. Aha! not so fast! the database doesn’t initialize before the server starts running so this thing simply doesn’t work. I wasn’t sure why and how it came to be. I was sure that node.js magic that it’s not multi-threaded, so there shouldn’t be a way that the app will start running before the DB finished its initialization.

Ideally, themes should be per user where the default is determined by the…. community(‘s founder?). Hello new model – Community. And now the developing spiraling to every direction. A better plan is in order.

To be continued…