I joined based on a friend invitation, then he didn’t attend...
It was two days hackathon...
Spent the first day trying to find any thing to do... but didn’t!
Slept in the place chatting and socializing...
In the second day, I found interesting JavaScript library, and decided to invest my time trying it...
Built a prototype in two hours, photoshop a presentation in two hours... waited 3 hours to the end of the event... present my Working POC...
Won second place and qualified to the world wide competition!

Discovered pro tip of my life :
Never trust your code

Achievements unlocked :
Successfully running C++ GPU accelerated offscreen rendering engine with texture loading code having faulty validation bug over a year on production for more than 1.5M daily Android active users without any issues.

History : Recently I was writing a new rendering engineering that uses our GPU pipeline engine.. and our prototype android app benchmark test always fails with black rendering frame detection assertion.

Practice:
Spend more than a month to debug a GPU pipeline system based on directed acyclic graph based rendering algorithm.

New abilities added :
Able to debug OpenGL ES code on Android using print statement placed in source code using binary search.

But why?
I was aware of the issue over a month and just ignored it thinking it's a driver bug in my android device.. but when the api was used by one of Android dev, he reported the same issue. In the same day at night 2:59AM ....

Satan came to me and told me that " ok listen man, here is what I am gonna do with you today, your new code will be going production in a week, and the renderer will give you just one black frame after random time, and after today 3AM, your code will not show GL Errors if you debug or trace. Buhahahaha ahhaha haahha..... Puffff"

And he was gone..
Thanks satan for not killing me.. I will not trust stable production code anymore enevn though every line is documented and peer reviewed.

'Hey I found a bug in your code, it's probably a typo, see here.'

Me: Oh right, yeah. How stupid of me. Thanks, I'll push it.

'It's okay. You can push it or I can do it too after you push the changes we just discussed. I actually simplified one of your methods.'

Me: You, what... ?
(You crammed multiple lines in a single line with your stupid as fuck, rigid constructs, removing my error handling, loosely coupled service, in the name of simplification?)

' Yeah it's just four lines in a single function now, no need to call the function again and again.'

Me: (No... Just no. This totally undos whatever little I could do to avoid supporting your idiotic object in the first place.)
Oh... okay, we'll see. I'll let you know.

What life.
Life in a company full of ignorant, inflated egos is no joke.

Details:
I created a service that reads a configuration file and returns the configuration. This person needs five entries for his app logic. He collected them in a object. Quite alright. Except that the class prototype is shitty. I, like a normal person, made my service return a value based on input. I was asked to incorporate this awful object so that I can return the five entries together, which is awful because the service is not supposed to know about how the entries are clubbed. It should most certainly not know about the data members of the object!

hehe..

What do you think about class-based OOP vs. Prototype-based OOP?
I think that class-based OOP is an unnecessary abstraction of structs, functions and global variables most of the time.

I hate it when we have weeks of planing, i know that it is important in soft eng but yet it is too long. I rather get a prototype, test it and get real results instead of daily brainstormings based on theories.
People need to grow guts and test !

Even if he's a younger guy than most other examples, my mention is:

Jordan Walke

He's the inventor of React, which probably changed the way to write (web-)apps for a lot of people and was based on a prototype written in StandardML.

He's also created ReasonML which is not only in many ways a more fitting language to write React, but also a good systems language (props to OCaml and it's unbreakable type system). Many React concepts/patterns have their origins in functional language concepts, including reducers and hooks.

Working for a large client converting paper forms to the web. Stated goals, simplify data entry for clients, improve data quality, reduce resourcing in backend human processing.

We met to review prototype and discuss workflow questions. Crazy deadlines, with the usual changing scope creep.

We start to point out the need for data validation, to shorten # of questions based on answers.

Business says no. All forms should be submittable regardless of what user enters, don’t put validations in because all that warning messaging confuses them and takes up more time.

Web form should behave like the paper copy....

Welcome to 1975!!! This is why 2018 won’t be like 2018...

JavaScript decided it wanted to be a Prototype based language because it needed to feel special.
Freaking Prototypes.

Classes > Prototypes

I wrote my first proper promise today

I'm building a State-driven, ajax fed Order/Invoice creation UI which Sales Reps use to place purchases for customers over the phone. The backend is a mutated PHP OSCommerce catalog which I've been making strides in refactoring towards OOP/eliminating spahgetti code and the need for a massive bootstrapper file which includes a ton of nonsense (I started by isolating the session and several crucial classes dealing with currency, language and the cart)

I'm using raw JS and jquery with copious reorganization.

I like state driven design, so I write all my data objects as classes using a base class with a simple attribute setter, and then extend the class and define it's attributes as an array which is passed to the parent setter in the construct.

I have also populateFromJson method in the parent class which allows me to match the attribute names to database fields in the backend which returns via ajax.

I achieve the state tracking by placing these objects into an array which underscore.js Observe watches, and that triggers methods to update the DOM or other objects.

Sure, I could do this in react but
1) It's in an admin area where the sales reps using it have to use edge/chrome/Firefox
2) I'm still climbing the react learning curve, so I can rapid prototype in jquery faster instead of getting hung up on something I don't understand
3) said admin area already uses jquery anyway
4) I like a challenge

Implementing promises is quickly turning messy jquery ajax calls into neat organized promise based operations that fit into my state tracking paradigm, so all jquery is responsible for is user interaction events.

The big flaw I want to address is that I'm still making html elements as JS strings to generate inputs/fields into the pseudo-forms.

Can anyone point me in the direction of a library or practice that allows me to generate Dom elements in a template-style manner.

Just some figma improvements from the perspective of a new customer:

* Copy/paste is broken. If I want to make a change, I have to create a whole new
component. They recommend cmd+c/v for copypaste but as far as I can see it does nothing

* Needs to be an explicit component drawer button instead of hiding it under assets. Through me for a loop for a couple minutes.

* Empty textboxes shouldn't vanish because you happened to click in the wrong location
while setting your properties.

* Text should start big enough to actually see.

* "send to back/front", "hide item", "change transparency' all need to be prototype actions and more, give us access to object properties both by parent/sibling/child, and by
object id

* create a new frame based on a specified size is non-obvious and if you're creating
a lot of frames, what with copypaste being non-intuitive, it can become laborious.
This is especially so when you're copying frames in order to make minor changes and observe the differences side by side, instead of potentially destructive edits.

* I see no obvious way to manage transitions/animations between frames.

* The difference between frames and groups isn't sufficiently explained. The words
frame, groups, and layers all appear to new users to be used interchangeably, even
if they are distinct things.