I Code Startups

Are you prepping up to participate in a hackathon?
Looking for tips to optimise your time and energy over the duration?

Here are a few things to keep in mind before you go in on day 1.

Hackathons these days (nights) are high packed with energy and enthusiasm. While the focus on fun is certainly great, don’t assume it to be just a picnic.

Most of the hackathons I’ve won involved working on a problem statement that the company had for a long time, but never a P0 issue. Your idea does not necessarily have to be a tech feature for the product. Think about the problems in the HR dept, an improvement to the hiring process, reducing overall carbon footprint? Bring out the engineer/designer in you – forget about the box.

If you do end up choosing a tech product – try breaking it into the set of features you need to implement. Prioritise your sub-features. It’s better to be able to demonstrate the end to end idea rather than have only the first part working.

Prepare for the hackathon early on. Think about the problems you can anticipate, this leaves room for unanticipated problems (trust me, there will be many).

Work on the presentation from the 0th hour.

Most teams which have done brilliant projects fail to showcase them owing to an improper presentation or lack of rehearsal.

The presentation/demo is one of the most (if not the most) important factors in deciding the winning teams. Tailor your MVP/Development around the narrative of the demo.

You might want to skip/abstract out the parts of the project which are not a focus area in the demo.

Lastly, remember that the real success of your project will be when you take it to fruition. Follow up with the org to try and create a plan around taking this idea to production. (albeit behind a flag). Keeping this in mind will help you write sane code.

P.S – do not rm -rf the project folder after you win *wink* *wink*

Go ahead hack on!

I would define currying as invoking a function with fewer arguments than the function expects. This returns a new function that can be called with the remaining arguments. You could also invoke it with lower than remaining arguments and it would return yet another function.

Sounds confusing? Let’s look at the expected behaviour of our curry function:

const add = (a,b,c,d)=>{return a+b+c+d}

let add2 = curry(add,2);
//Here add2 is the curried function. We can use it like:

add2(3,4,5) //results in 14 (2+3+4+5)
//or
add2(3,4)(5) //Same result
//or
add2(3)(4)(5) //Same result

//This works too -
const add2_3 = add2(3)
//The above will now accept two more arguments.

add2_3(4,5) //results in 14 too.

How would you go about implementing this?

Those of you who read my blogs regularly, already know that I have been coding for the better part of the past decade.

A fair bit of that time has gone into building beautiful and usable UI components for projects built for scale. (e.g. Fab, Hem, Tavisca)

So it was not a surprise for me when I saw that RoR community came up with SASS a preprocessor for CSS which allowed you to dynamically create your style-sheets. Eventually, developers could use functions (mixins, extend, import), variables, nesting and create UI components in a much elegant fashion.

All was well, the UI developers were still writing their styles in a separate file which would compile down to CSS and be included into the HTML as required.

But eventually, with Angular and React, users started writing their styles in the HTML directly. It felt natural to new developers who liked keeping their HTML/JS for a component in a single JSX file. They had no qualms about using CSS in the style attributes of their DOM nodes.

Even though in my opinion (please note the term ‘Opinion’) inline-styles pollute the DOM and get in the way of development.

Also, keeping styles for each component in its own JSX makes it difficult to use the power of SASS and visualize the entire hierarchy that we get by looking at a SASS file (if done properly.)

Enter, styled-components which lets you write CSS as JSON objects and auto assigns a unique class name to every component. It also auto links the class to every instance of the component.

What I dislike about this approach is the fact that we are adding inline-style nodes and the browser has to generate the same class during every execution of the app/page. This does not play well with the fact that browsers can easily create the class, pre-process its properties and cache it for future use across reloads.

What are your takes?

This morning I received an e-mail on my HipChat linked account.

According to Atlassian, they have detected an incident that may have resulted in unauthorized access to my user account information which very well includes the username, email address and hashed password.

They go ahead to mention that there is no evidence for other Atlassian products having been breached. They also claim that they did not detect any unauthorized access to financial data.

While Atlassian may have already deleted your password to force a reset, my recommendation is to change your password across other websites if you happen to re-use your password.