DEV Community: Elliot

What is Dev Like at a Canadian Startup? 🤔

Elliot — Mon, 03 Jan 2022 18:58:02 +0000

Hi, I’m @elliot 👋. I’m a Front End Developer on the Opslock Engineering team. I joined the team just about a year ago now, and I want to reflect on what it is like to work here. I interviewed each of the Opslock Engineering team members (there are nine of us) and asked six questions in an attempt to collect some words and ways to think about what being an engineer here is about. Each of these six questions is a heading in the post below. Under each heading is a selection of a few of the most interesting responses from the engineers. With that being said, I’ve tried to fairly represent the perspectives of all the engineers.

Why am I writing this? I asked for some time to write this blog post by pitching it as a form of viral marketing that “will promote a positive view of Opslock’s technology to our existing and potential customers”, and “will be a resource for attracting new engineers”. Really though, it’s just an excuse to spend work hours talking, journaling and contemplating my own career… Facetiousness aside, the team was supportive and encouraging during my writing of this post. If you are interested in working at Canadian startup, I have certainly tried to make this post useful to you.

Alright, let’s get to the questions.

How would you explain something you’ve worked on to someone outside of Opslock?

SHAWN
“So I think in general, you know, we’ve just had the mantra of ‘nothing on the front end is set in stone’ and […], you know, we encourage people to try new experiments. And then, I think that the whole team is pretty good about if they see someone doing something that is just a better way to do it; that knowledge spreads very quickly through the team and it just becomes the default way to do it. And then eventually we have to go back and do it for the old code, but that’s the downside of doing it this way. But I think it really allows us to sort of slowly find a workflow that works for us.”

BEN
“So far. I’ve touched a little bit of everything, so less specialized, but I worked with Memento and Notify.”

“Notify is our notification sending microservice and the purpose of it is to allow users to receive notifications whether they’re on premises, on an industrial work site and/or whether they’re working from the headquarters of a company somewhere in a major city.”

“So that was really the biggest challenge: being able to send notifications as […] someone goes in and out of a wireless internet connection while going across the ocean.”

JOHNNIE
“Replicate? Okay. So yeah, replicate is an in-house replication system that copies data from multiple databases in a master-master fashion, or we call it active-active.”

“We kind of know what kind of rules we want for when writes and reads occur between one site to another. And it’s one of those cases where the solution out of the box doesn’t provide all the customization you would like. And also if we want to do maintenance on a piece of work like this, we want to be able to understand what’s really happening under the hood. So for us it made more sense to write one in house and add the features we need as we need them.”

“And also we wanted to be able to have the ability to control how much data goes over the wire and how big is the deliverable, because we’re pushing these changes to on-prem devices, IOT devices.”

BJORN
“And the [Opslock] design system? I’ll say it would be like any other design system, the building blocks for whatever you see on the screen. And it helps developers to build things quickly and it kind of makes things more rigid and robust.”

What is the most interesting part of your job?

AIDAN
“Well, the fact that we work in a startup also [means] that our responsibilities are a little more cross spread, like cross-pollination [of our] tasks.”

“So I guess the most interesting fact is that our responsibilities are not stuck in stone. And, and if something really interests you kind of can go forward with it and go explore it a little.”

BEN
“We have a strong bias towards building our own tech in Go instead of just including a bunch of technologies from all over the place. And we always try to find Go technologies first before including other programming languages into our stack. So instead of just adding some big Java-something that runs in the background, we try and find a Go alternative or we write a Go alternative. And that keeps things really light and slim, but it also gives us hands-on engineering experience, building simpler versions of those really complicated Java things. So we get to learn a lot of different stuff.”

JOHNNIE
“I think the most interesting part of the job is designing the backend solutions to our problems, just because when we’re often thinking about solutions, we’re thinking about how they are solved twofold. One is online and one is on-prem.”

“That’s kind of interesting to solve rather than working on a cloud-based product only. It’s kind of straightforward when you have access to using whatever SAAS tools you want. But when you do backend solutions that require on-prem, you have to think about if you can’t use a SAAS tool, most cases. It adds: ‘Okay, we have to build some.’”

MARC
“I would say, having to deal with on-prem devices that sync with the cloud, that allows customers to use the service even when their work-site is offline [and disconnected from the internet], as long as the app has a working local network. It’s the most interesting part because it’s the most difficult part [and] is the part that makes Opslock differentiate itself from other companies that might offer a similar product.”

“It’s a bit mathematical in a way too.”

BJORN
“Because it’s the first time we [are] working [with Svelte] on an enterprise level and we are solving problems that not many company has solved before with a new framework. I’m pretty happy that we are discovering ways for it. We are paving the path forward for this new kind of framework we’re using.”

LUCAS
“In general, I find the grooming process for new features is the most interesting part. It lets me imagine a blueprint for how to implement a feature. And then, when I implemented and finally got everything into one piece and I chain everything together. I feel it’s the most interesting part.”

MICAH
“I love technology, but ultimately I view it as a tool to complete another goal. So it’s understanding how people will interact with something, it’s understanding how people could interact with something, how it could be broken, how they could expect something to behave and then finding thoughtful ways to implement it for future developers or myself.”

What is your day-to-day work like?

BEN
“I’m just doing a lot of reading and building microservices. I guess most of my day is just building and testing stuff, but I don’t really know how else to answer that.”

JOHNNIE
“My day-to-day work, for me normally, begins with after I warm my brain up: going over some PRs and things like that, then I’m prepping to see what my team is working on. Cause I’m a technical lead for a squad. So understanding where my team members are at and understanding what can I do to help them, and what can I do to help facilitate them help them help each other? Because at the end of the day, I don’t see myself as like the boss or the leader, but I see myself as the facilitator to just kind of help get things done. I want to just make sure they have what they need.”

“I think we’re all leaders here at the end of the day. We all have very strong thoughts and I like to have everyone really have ownership in what they’re doing. I think the goal is just making sure that there’s always alignment and having someone take control of that alignment, but everyone provides good thoughts on the engineering team. I like to be the facilitator to let those thoughts come to fruition.”

MARC
“Fortunately, my day-to-day work does not involve too many meetings. I’d say maybe 20% meeting, 40-50% actual work, which is pretty good compared to past experience. Another fraction about helping others that might have technical issues with the product. And I also take the time to research and think about the future and what we could do best in the future.“

What’s your take on the mission of Opslock?

SHAWN
“When we got our first customer [customer name removed]; Johnnie, Joe and I flew out to Newfoundland and set up the onsite server on their boat and they showed us around the boat and stuff. And this was a more modern boat, but they were still doing most stuff with pens and paper.”

“They had binders they showed us: ‘yeah, here’s where we fill out the thing and we just check it off.’ and it’s this big bookcase of binders. And you know, it’s impossible, if you need to search for one work permit that happened three months ago. Good luck finding it, right?”

AIDAN
“So there’s not lots of places where we can say that we’re actually […] trying to make the workplace a more secure place, like where we can actually have an impact on security [safety] and maybe even lives.”

JOHNNIE
“I think my take is simply we’re building tools to make risky jobs easier to do or safer to do.”

“There’s a lot of friction going on with those industries and we’re trying to solve that friction.”

MARC
“My interpretation of the mission is that there’s a lot of friction right now in the industry when it comes to health and safety, a lot of forms and checkboxes to tick and things like that. When it comes to security, it’s ironic because too much security actually can decrease security.”

“You don’t increase security by adding more stuff to do. You make it super easy. You use computers instead of [paper] forms, but you don’t, you don’t fit-in forms on your computers. It’s a bit better, but that’s not what you do. You want to automate. You don’t want to have anything to do, and [automation should] do the health and safety analysis for you. So, yeah, removing friction.”

MICAH
“So coming from a background of mechanical engineering, I worked with industrial companies and I saw how they maintain their documentation and how they tracked work, let’s say, or how they try to ensure safety or how they even track systems. I worked with subsea departments, so looking at installed hydraulic equipment and seeing how that is monitored and tracked. And then I’ve worked with work departments where they’re talking about budgeting people’s hours for work. And one thing that really kind-of astonished me at the time as an undergraduate student and these co-op terms was how behind they were technologically at the time… And how Excel makes the world go round!
And like someone in an office can run Excel and that’s fine, but nobody who is in a trades position or who in an implementation position is going to pull up Excel and log it? It doesn’t make sense! It’s so much friction. And it’s so non-intuitive, it’s a great tool, but the reason why people make paper documents, which tell you where to sign and what you’re signing, is because it makes so much more sense than giving a trades worker a pen and paper and say: ‘why do you think this is safe at this given moment?’ Right? So the thing that I love about our mission is it lets people focus in real-time on what they are doing as far as dangerous work is concerned, as far as trying to talk about dangerous work.

And it guides them along that path to be more effective communicators and more effective maintainers of the integrity of the safety around the work they’re doing. And then to implement it, right? Because the more we lower the friction for the paperwork that they have to do to ensure compliance, the better that they can focus on actually being safe Because we’re telling them exactly what they need to do. So, I just, I really like it because I know the friction exists and the reason why we do it is because the work is inherently dangerous. So it’s kind of fulfilling to be like ‘we get to take it off your plate,’ you know?“

What have you learned while working at Opslock?

BEN
“I learned a lot about how to keep architecture simple and how to not overcomplicate things.
Johnnie and Marc are both very good at the ‘don’t prematurely optimize’ mentality. And that’s something that I’ve had trouble with in the past.”

JOHNNIE
“You start to understand when you solve problems, you’re normally solving now for what doesn’t work rather than what does work; because there’s always multiple ways to solve the problem, but oftentimes we’re always like ‘what’s the first thing that works?’ But I think what I’ve been learning is [that] you want to remove ambiguity all the time. So you want to remove things that don’t work and then leave yourself with a set of options.“

LUCAS
“I think the most important thing is there are many ways to solve a problem, and I learned how to find a solution, the best solution, for this issue. And just thinking in the long term, I think that’s the key.”

MARC
“I’ve had the chance at Opslock, when building the backend, to actually be part of the discussion about the design, the architecture, and how to tackle problems.”

“I have learned a lot about how to tackle the problem and what matters and what does not matter. Cause there’s plenty of stuff to fix all the time. I don’t run out of stuff to do, but you have to be able to know what needs your attention right now and what can wait. And it feels weird sometimes to say here’s a bug, but I won’t fix it. Even though I notice it, even though I know I have a good idea on how to fix it, I just won’t fix it now.”

“So yeah, I learned to prioritize and also at Opslock, I’ve been allowed to fail. Like there are things that I’ve implemented and it turned out to be very bad, and I just propose another solution for my mistakes. I said, well, we should do it this way instead. And I was allowed to redo it. It was not like: ‘no, you had the chance and we’ll ask someone else’ or ‘we’ll just keep that crappy solution because it kind of works. It’s fine.’ If I know how to make something better, I’m allowed to do it. So that helps the learning experience.“

MICAH
“For me as a developer, I learned a lot of new technologies because we’re very quick to, kind of, use new shiny things, which is a fun part of being a startup. If you want to implement a technology, you can fight to do it… If you think it’s going to give business value.”

“I think being your own advocate too, is another thing that you have to be in a smaller team. Maybe in a larger team, you can kind of hide in the background a little bit more.”

“This team loves to share excitement, and I think that’s a lot of fun. If you make a strong case for something then people will be like: ‘yes, we do need that. Let’s get it moving!’ Whereas in larger teams, I can imagine there’s just more, a little more bureaucracy to making those changes.”

What’s your favourite part of Developer Experience (DX) at Opslock?

AIDAN
“So we’re slowly building the CI that we want. Bryan listens a lot to his engineers. Not that he’s like… sometimes he has his ideals and he may be stubborn sometimes. But I mean, if you have good arguments, he will listen to you. Like, He didn’t know nothing about Scaffold, about Memento and all that, but Marc-François presented those and said: ‘look, it could be useful’ and he said: ‘okay, I don’t know what it is, but it seems good. Let’s go ahead.` So slowly, our CI is getting better and better.”

BEN
“Everyone is tech savvy. They are completely comfortable with just instantly hopping in on video calls or, or screen sharing, or using a Visual Studio live sharing. I think that’s the biggest… There’s the least amount of friction collaborating with people at this company that I’ve ever experienced so far.”

MARC
“I might be biased because, as someone who’s part of making the developer experience, I’m building the tools.”

“My favorite part is that if you have a brand new computer and you’ve just got access to the GithHub repo to get the code, and you have Docker installed, it’s one line, pretty much one line, and you’ve got your backend running and you can open the app. You can add users, add companies, do tasks. Like the friction is pretty low. I know it’s not perfect, but it was worse in the past. And it just, it keeps getting better.”

BJORN
“I feel glad that we have these, kind of, building blocks [from the Design System,] to speed up development. And yeah, sometimes I’m looking at files just full of Design System components and nothing else. It’s really cool to see.”

“Another thing is we have very extensive tests. I mean, for CI. So every time we do some changes currently we have a big list of CI checks that we do. And the good thing is we always have them green these days and it’s really assuring as a developer that we’re not missing.“

MICAH
“I think that the design system was a really smart move from the get-go. Just because previously we had used libraries, and there’s a lot of great libraries out there. It’s not to say that ours is the best. […] it just lets us have a level of control and customizability around the application that might be hard otherwise… and it ensures consistency.”

LUCAS
“Yeah, many things! I really like [that] we are building a fantastic CI on every repository, and it’s cool DX. And then secondly, I really like the group discussion[s we have] to solve the problem, and anyone can propose a solution and then we figure out our best fit.”

“Also I really liked the hackathon. And we can, besides the customer request[s], we also have the chance to propose our own requirement, which we think of, if we think there’s a chance we can help the customer in another way.”

Anything else you’d like to say?

SHAWN
“I mean, besides, you know, working in an early stage startup and working on a good team, what I would say is… The mission of Opslock is more compelling than a lot of engineering jobs out there. You know, there’s so many tech companies where you’re like just creating AB tests for some ad or: ‘which user interface is going to get more clicks than this one.’ It just feels so soul-crushing to me. I was nearly hired at a company like that, and I’m so glad I ended up here instead, because at least I feel like, oh, it’s very clear. There’s a very clear goal here.”

“I just feel like, look, whatever industry it is, people are losing hands and stuff, doing this, right? And hey, if we have software that, you know, reduces the number of hands lost per year, that seems like a positive outcome.”

“You can feel proud and excited about that without any sort of moral qualms within yourself. And I think there’s a lot of technology companies, not all of them, but there is a good amount where I would feel somewhat morally conflicted about the success of my own company.”

AIDAN
“When I get a little stressed and all that, and I’m like, oh, I just think of the team. And I like the colleagues I have.”

MARC
“There’s no unnecessary pressure put on me. If I have good ideas, they will be listened to. The tech is also cool to play with, I think, if you like Go. I guess on the front end, I suppose so too, I don’t do front end that much, but Svelte seems pretty cool. There’s also a good culture… The tech culture is there. People are interested and passionate about the tools they use and the programming language, without being too much… What’s the word? Well, without being fan-boys in a way“

“We like cool tech, but we like cool tech that gets things done.”

BJORN
“I would say that if you’re working from anywhere else, not in Canada, then take a shot. The team has been really, really helpful in making you part of the team and making you feel included. Anyone, new hires, feel free, not just in Canada, if you’re anywhere else, it’s a good opportunity.”

ME to LUCAS
“Other engineers call you the machine. Why is that?”

LUCAS's response
“I don’t understand when Joe called me that the first time, when I was in Opslock in my first year. I did some research actually. It’s like… just doing something like a robot and it’s never stop[ing] or some explanation like this. I find that it’s a positive compliment, so I accept it [laughs].”

“So I think for any potential hires, I think I can say that we grow very fast, we are still young and we have a lot of things to learn. So we welcome everyone that wants to learn new things and wants to grow together.

MICAH
“What’s exciting about working on a product like this is it’s not inherently super esoteric. It is in some ways, when you talk about predictive mitigation for instance, that could be seen as a little bit out there. But I think we’re making something for everyday people to use who have important roles in society. So I think that’s neat and fulfilling.”

That concludes the responses from the team! Interviewing my co-workers was a fun, collaborative, and insightful way to reflect on my first year here at Opslock. I’m happy to be able to share that insight with you in this post. Thank you for reading. Thanks also to the engineers and to Melanie, Opslock's designer, for making the line-art illustration for the header image of this post! If you are interested in joining the team, please visit Opslock's careers page here.

9 Months Into Our Web Monetization Journey

Elliot — Tue, 02 Feb 2021 02:45:40 +0000

Hi DEV! @elliot and @sharon here :)

Project Update

We're four months into our six month Grant for the Web project, Akita. What is Grant for the Web?

Grant for the Web is a $100M fund to boost open, fair, and inclusive standards and innovation in Web Monetization.

Check out our other articles under the esse-dev organization for context around the Akita project. You can also read our full interim report posted on the Web Monetization Forem. Now, onto the updates!

So far we've:

created "A Web Monetization Story" for helping creators on the web engage with and understand Web Monetization;
improved the Akita browser extension and released it on the Chrome Web Store (stay tuned for a post asking for feedback!); and
participated in: Creative Commons Global Summit 2020, Future of Micropayments Conference 2020 and hackathon communities to talk about Web Monetization!

We've been enjoying coding, designing, writing and chatting as part of the Web Monetization community. Some of our big wins have been placing 2nd🥈 in the BetaHack "Fix the Internet" hackathon with "A Web Monetization Story", having our projects and presentations featured on developers.coil.com and receiving our first issue reported by a community member on Akita. Our main struggle has been balancing development of the Akita extension, along with community outreach and development of our website "A Web Monetization Story".

How can I support Akita

If you have some spare time, check out "A Web Monetization Story" and fill out the survey at the end to let us know your thoughts! (If you’ve already checked out the website, but missed the survey, you can fill it out here: "A Web Monetization Story" survey).

Finally, we’ve created a Twitter account for us to communicate updates on our progress going forward — we’d appreciate it if you gave us a follow: @esse_dev. Not much going on there yet, but stay tuned! :)

Closing Thoughts

Over the course of the project we've learned about open content and open source licensing, incorporation in Canada, privacy policies and browser extension development, among other things. Elliot gave his first conference talk and Sharon published her first browser extension: Akita!

Shout out to the Web Monetization community! We've appreciated all the support we've received since we started on Akita nine months ago. It's been awesome to speak at conferences, receive feedback from the community and meet so many cool people.

Thanks,

the esse-dev team (Sharon and Elliot)

A Web Monetization Story

Elliot — Mon, 24 Aug 2020 05:38:38 +0000

@sharon and I are creating A Web Monetization Story, an interactive Web Monetization tutorial for online creators. The tutorial follows along with Auden, a blogger who is experimenting with Web Monetization on their site. If you are interested in setting up Web Monetization on your own site, or want to get others involved in Web Monetization, you may be interested in A Web Monetization Story.

We are creating this project for the BetaHack ‘Fix The Internet’ virtual Hackathon. There are seven days remaining in the hackathon. We are posting here, on DEV, in order to ask for honest feedback on what we have created.

We hope that you enjoy what we have created. We also hope to keep improving on it, so we want to hear from you! Thank you for reading and supporting us!

Excerpt

I run a blog about my adventures with Chicken — my dog!

Recently, I came across something called Web Monetization. It’s a new way for online creators to monetize their sites and for website visitors to support creators. It seeks to promote a more flexible, inclusive and privacy-respecting way of transferring money.

P.S. vote for @sharon in the 2020 HackerNoon Noonies - Best Web Monetization Innovator Category!

Hackathon Update: Breaking Our Idea Down Into Dog-Treat-Sized Tasks

Elliot — Tue, 02 Jun 2020 05:36:26 +0000

@sharon and I are continuing to work on our #GftWhackathon project. For our submission, we are making Akita! Akita is a browser extension that gives you insight into your involvement with Web Monetization. We have broken down our browser extension creation process into 8 tasks. We use GitHub to manage our tasks; you can see all our comments, related code, and progress on Akita's GitHub page. In this article I list our tasks and give a brief explanation of each of them. We have finished ✅ some already, and we are still working 🚧 on the others.

For a backstory and explanation of the thinking behind Akita, check out the article @sharon wrote:

How can you support websites without having to deal with annoying ads?

Sharon for esse-dev ・ Jun 2 '20

#gftwhackathon #webmonetization #webdev #browser

Here are our 8 tasks for creating the Akita browser extension for the #GftWhackathon:

✅
1. Commit basic project structure

Create a "hello world" browser extension.

✅
2. Check for monetization meta tag on a webpage

Check whether the "monetization" meta tag for a payment pointer exists on the site.
Validate the payment pointer according to https://paymentpointers.org/ and https://interledger.org/rfcs/0009-simple-payment-setup-protocol/#specification.

🚧
3. Change extension icon dynamically from JavaScript

When a user is on a monetized website, the Akita extension icon in the browser bar should visually change to make it clear that the site is monetized.

✅
4. Figure out how to store data without relying on browser search history

Store data using browser.storage.local. Write helper functions to make sure data is stored in the expected structure, and data is not accidentally overwritten.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage

✅
5. Data collection: Track amount streamed to websites

Use the Web Monetization JavaScript API to listen to monetization events and collect data through the extension. The API is available to website developers through functions in the document.monetization object. This ended up being a challenge because the document.monetization object is not directly accessible in the browser extension JavaScript runtime environment, so a script must be injected into the webpage to access it.

🚧
6. Data collection: Track # of visits to websites

Track and store total number of visits to monetized sites vs. unmonetized sites.

🚧
7. Data collection: Track time spent on a webpage

Track and store total time spent on monetized sites vs. unmonetized sites.

🚧
8. Load collected data and display it in the extension pop-up

When a user clicks on the Akita extension icon in the browser bar, a small window will pop up which visually displays all of the collected data, whether the current page is web monetized, and links to resources for getting involved with Web Monetization.

Thank you for reading and following our progress in the hackathon! I've seen that some people have already posted some cool submissions. I'm excited to be getting involved in the growing Web Monetization community and can't wait for @sharon and I to submit Akita :)

Kickstarting a project idea: going from 0 to...0 - Part 2

Elliot — Tue, 26 May 2020 03:20:10 +0000

For the past two weeks, @sharon and I have been working together (across the country!🇨🇦) on the Grant for the Web Hackathon #GftWHackathon. We've spent our time researching Web Monetization, learning how to effectively collaborate and organize our work, and coming up with ideas for our submission.

In this post I will talk about the ideas we came up with, the problems we encountered, and the current state of our progress in the hackathon. To read about how we began our remote collaboration process check out @sharon 's article:

Kickstarting a project idea: going from 0 to...0 - Part 1

Sharon ・ May 26 ・ 7 min read

#gftwhackathon #webmonetization #ideation #collaboration

Top 3 Grant for the Web x DEV Community hackathon Ideas
Money stream visualization (Sharon's Idea) A Web Monetization enabled website could include a visualization of all the different streams of money being sent to the website. Each visitor could be represented by a colored shape. If a visitor is streaming money to the website using Web Monetization, $s could flow out of the shape representing the visitor. If there were a ton of people streaming, there would be a ton of $s flying across the screen! The speed at which the $s flow out could represent the payment stream rate, e.g. how much money is being sent per second. It would be possible to implement this visualization by using the Web Monetization JavaScript API. On the frontend of a website, The JavaScript API would collect information about whether a user is streaming money or not. That information would then be sent to a backend server which can keep track of the money-streaming data of all users on the website. The backend would then send all the data to the frontend to be visualized. This idea would provide a visual way for website users to get excited about and engage with Web Monetization! When people see a cool visualization, they might be interested in learning more about what it is communicating. It would be important to provide links to resources and information about Web Monetization so interested people could learn more and become part of the Web Monetization community. Additionally, the idea of streaming money is new and may be a bit tricky for people to wrap their heads around (we thought it was tricky!). Seeing a visualization might help newcomers understand what it means to stream money over the web!
Live event platform (Elliot's Idea) Attending events in-person can be a lot of fun, but unfortunately most in-person events in the near future have been cancelled. An online event platform could fill this gap and enable people from across the world to attend events together. Charity and fundraiser events can be a great way to connect with a community of like-minded people, have a good time socializing, and contribute to something meaningful. With the power of Web Monetization, online charity and fundraiser events could easily be created. Just by attending and spending time at an event, a person using a Web Monetization provider would automatically be contributing to the cause supported by the event.
A website with a central fund which is distributed based on merit (Sharon's Idea) Here's the idea: website users stream payments to the website using Web Monetization. As they spend time on the website, the streamed payments are collected into a central fund. Then, the money is distributed to contributors based on some measurement of merit. This would help promote quality contributions by rewarding the contributors who put in the effort in a more tangible way...money! For example, StackOverflow.com could collect streamed payment from its users. All the money collected could be given back to the best-rated accepted answers on the platform. Bonus idea: What if every time you upvoted an answer on StackOverflow you sent a microdonation? This would allow you to give the answer’s author a small gesture of appreciation, with a bit more of a personal touch than an upvote on its own.

While discussing our top 3 ideas, we realized it might work to combine the Live event platform and Money stream visualization ideas. We thought it could be hype-inducing to attend a live fundraising event which gives you a visual understanding of the total amount of money being streamed during the event. We decided to combine Sharon's idea with my idea into one SUPER IDEA: A live event platform with money stream visualization. This super idea could enable users to feel like they are part of the community, have fun, and contribute to a great cause!

At this point we were feeling good about our new super idea, so we started moving ahead with it. The next steps were to define features and figure out how users would interact with the platform. We had done our research and we knew it would be possible to implement our ideas using Web Monetization tech, but we weren’t sure whether our idea would actually be useful or not. As we were getting into the details of our idea, we identified a few problems that seemed difficult to address within the scope of our idea.

More money, more problems

While thinking about how real users would interact with our SUPER IDEA, we asked ourselves the question: How many Coil users would have to attend an event in order for the event to raise a significant amount of money? Since Coil is currently the only way for users to stream money using Web Monetization, this was an important question. We checked Coil's documentation and found that Coil streams money at a rate of $0.36 an hour to websites. Assuming, for simplicity's sake, that each user attends an event for an hour, our platform would need 1000 users to join an event in order to raise $360.

That's not a very large amount of money, but it is a very large amount of users, and a long time to spend at an online event. We felt that creating a platform for such an event sounded quite difficult: it is not easy to attract people to an event, and it is even harder to keep people engaged for an entire hour.

In order to keep people engaged for the length of an hour long event, people would have to be actively engaging with something. Combining our Live event platform idea with the Money stream visualization idea would give people an interesting visualization to look at for a minute or two, but certainly not a full hour! We started thinking about YouTube and Twitch. These platforms keep people engaged by hosting high-quality entertaining content. Making a great platform for content doesn't seem easy…

With these considerations, making our (maybe not-so) SUPER IDEA useful sounded like a complex problem—too complex for a month-long hackathon. So we decided to pivot to our third idea: A website with a central fund which is distributed based on merit.

While we both agreed that this idea is cool, we quickly realized it would be more useful when added to an existing website. Creating an entirely new platform just to add the idea of rewarding contributors with money is a bit backwards. What kind of platform for contributors could we even establish when so many great ones already exist? We decided it would be great if existing platforms like Stack Overflow incorporated this idea into their community, but we didn't think this idea was the right fit for the hackathon.

We had run out of ideas.

Feeling lost, sad, and hopeless is part of the process

Now, at the time of finishing this article, I can add that writing has helped us step back and understand where we are at in this hackathon. While working through the details of our ideas, we encountered unexpected complexities. We ended up feeling stuck and we didn't know where to go next. So, we took some time to think, discuss and reflect on our frustrations, and write down our thoughts. This process allowed us to revisit what we valued in Web Monetization and what we valued in our ideas. After our feelings of frustration were resolved, we were able to move on. All the time spent, and knowledge gained from this frustrating process is exactly what we are using to come up with a new idea.

We have come up with a new idea which takes what we valued from the previous ideas and combines it into not just a SUPER idea, but a MEGA idea. We've learned firsthand that it can be good to pivot and change ideas. Pivoting is like starting over again, but with way more understanding and knowledge than the last time you started over. In summary, failing can be great (even though it's difficult and frustrating)!

Wish us luck as we get started with our new idea in the last two weeks of the hackathon. All the best to our fellow #GftWHackathon participants, and see you in our next update post!

My Google Technical Interview Cheat Sheet

Elliot — Sat, 06 Jul 2019 12:44:27 +0000

Introduction

In the last couple of months of 2018, I spent most of my days preparing for my Google Internship technical interviews. I ended up getting the job, and had a great experience!

Two months after my internship, I wanted to share the document I used and prepared in the weeks leading up to my interviews. For me, creating this cheat sheet was like creating a cheat sheet before an exam. The process of creating it and checking the steps over and over solidified the steps in my mind.

I believe anyone can pass interviews at the big tech companies, you just have to spend time learning about the interview process and preparing.

This document is high level enough that it should be applicable to any sort of technical interview, whether you are applying to Google, a startup, or your first internship. I hope it can help you feel more comfortable in your preparation and interview process!

Technical Interview Cheat Sheet

Resources

https://www.pramp.com/#/

An interview practice tool. Take turns interviewing and being interviewed by someone with a shared code editor, and video and voice chat.
The best resource. Interviews may be awkward or difficult at first, but the more you do, the more comfortable you will be, and the better you will do in a real interview.

https://codesignal.com/

Good questions from real interviews at Facebook, Google, Microsoft, etc. I recommend codesignal over alternative code practice websites, because most questions include a target space and time complexity.

(Cracking the Coding Interview)

My favorite parts: Interview Preparation Grid (pg. 32), the whole behavioral questions section, and Interview Questions: Data Structures (pg. 88 - 107). If you haven't encountered space and time complexity before, this book has a good, quick, practical introduction to the concept.

Throughout the Interview:

Consistently communicate, with honesty. (Keep talking while you are thinking, communicate your thought process)
Chat, joke around, have fun.
Write down any important information.
Ask questions, and adapt to what the interviewer gives you.

Step by Step:

These are the steps I followed from the start of the technical interview to the end. Don't worry about getting through all of them, just get as far as you can, giving each step as much attention as it needs. (In one of my interviews I only just started on step 9 before I ran out of time). When I got off track I found these steps helped me reorient myself and keep going.

Read Question
Clarify understanding of inputs, outputs, and side effects
Ask questions, and state any reasonable assumptions
Go through an example to ensure understanding of problem
- Spend as much time as you need just understanding the problem, this is important
Think of an algorithm to solve the problem
- Try a similar, but less complicated problem.
- Try paying attention to your process in manually working through an example.
Go through an example or three to make sure the algorithm works
- State any edge cases and address them
Discuss Time and Space complexity
If you can think of a better algorithm, and you have time, go to step 4; otherwise ask if this is good, if it isn’t, go to step 4
Implement
- Break the problem down into several methods (if it is good to do so)
Look over code for errors.
Think of edge cases arising from how your algorithm is implemented.
Go through an example with the implementation, looking out for errors.
Once you are sure your code is correct, clean it up.

What was your favorite song/album/artist to listen to while programming this week?

Elliot — Thu, 13 Jun 2019 21:35:50 +0000

Community highlight: Last week t4rzsan shared some consequences of wearing headphones while working in the article: Why you shouldn't wear headphones while working.

Protip Spotify Embed: Enter the Spotify URI of the Spotify track / playlist / album / artist / podcast episode you are trying to embed.
{% spotify spotify:episode:5V4XZWqZQJvbddd31n56mf %}

Whether you are quietly jamming to tunes in the office or blasting some beats at home, what was your favorite song/album/artist to listen to while programming this week?

What are your favorite creative coding articles, tutorials, and content?

Elliot — Sat, 08 Jun 2019 22:42:39 +0000

Visualizing Process with Javascript ES6 Generators

Elliot — Fri, 07 Jun 2019 13:33:38 +0000

Countless hours are poured into designing functions that run in the fraction of a second. When functions execute so quickly, their ingenious implementations are not easily appreciated. Let’s slow them down, and take the necessary time to watch them work.

In this article, I go over the basics of generator functions and how to use them to visualize a function’s process.

What's a Generator Function?

Generator functions are new to JavaScript, and many people have been struggling to find real-world practical uses for them. I’m excited to show you a cool way to use them, but let’s go over the basics first. Here’s a simple Generator function:

function * myGeneratorFunction(arg) {
        yield 1;
        yield arg;
}

It looks a lot like a normal function except for two differences: an asterisk (*) after function, and the use of the yield statement.

Below is how myGeneratorFunction is used:

const generator = myGeneratorFunction('hello world');

console.log(generator.next().value)
// logs out 1

console.log(generator.next().value)
// logs out 'hello world'

Calling a Generator Function does not execute it right away, instead it returns a Generator object. Calling .next() on the Generator object causes myGeneratorFunction to execute up to the first yield statement, returning the value appearing after the yield keyword. Generators allow us to stop and start the execution of a function. Check out the the MDN page on Generators for more information.

Why visualize a function's process anyway?

Visualizing a function’s process helps when trying to understand the implementation, and can result in fascinating animations and impressive effects. Take this video visualizing various sorting algorithms for example:

This video illustrates why process visualization is awesome:

Watching the process of sorting is strangely captivating.
The differences in how each sorting algorithm works are instantly obvious.
What better way to interest someone in how something works, than to make how it works look cool?

Let's visualize!

Computers nowadays run ridiculously, faster-than-Usain-Bolt, mind-bogglingly fast. That means that functions run just as fast. With a Generator we can slow down the function process so that it operates at 60 steps per second. At this speed we can watch a function do what it does best, in real time as it does it. It will be like watching the world’s fastest sprinter in slow motion, seeing individual muscles contract and relax in a single step.

For our example let's shamelessly copy the youtube video above and visualize the insertion sort algorithm with a bar graph. Below are two pieces of code we will need. One for the basic algorithm, and one for drawing a bar graph. After these pieces of code, we'll see how to easily put them together.

This is the basic insertion sort algorithm implementation:

function insertionSort(inputArray) {
    for (let i = 0; i < inputArray.length; i++) {
        const value = inputArray[i];

        let j = i - 1;
        while (j >= 0 && value < inputArray[j]) {
            inputArray[j+1] = inputArray[j];
            j -= 1;
        }
        inputArray[j+1] = value
    }
    return inputArray;
}

And below we have a function that draws an array as a bar graph on a canvas. I use the 2d Canvas API:

const c = document.getElementById('canvasEl');
const ctx = c.getContext('2d');

function drawGraphFromArray(array) {
    ctx.clearRect(0,0,c.width,c.height);
    const barWidth = c.width / array.length;
    const barHeightScale = c.height / Math.max(...array);

    array.forEach((value, i) => ctx.fillRect(
        i * barWidth,
        0,
        barWidth,
        barHeightScale * value
    ));
}

draws a bar graph where x axis: index in the array, y axis: value at index

Now back to our regular programming. In order to slow down our insertion sort function we are going to rewrite it as a Generator function. Sounds tricky, right? It’s actually the opposite of tricky, it’s SUPER EASY. This is the rewritten insertion sort:

function * insertionSort(inputArray) {
    for (let i = 0; i < inputArray.length; i++) {
        const value = inputArray[i];

        let j = i - 1;
        while (j >= 0 && value < inputArray[j]) {
            inputArray[j+1] = inputArray[j];
            j -= 1;
            yield inputArray;
        }
        inputArray[j+1] = value
    }
    return inputArray;
}

There are only two changes. We add an * after the function keyword and add a yield statement whenever we want to draw a frame in the animation, yielding the array being sorted. With those simple changes, we’ve converted a function into a Generator function that is executed one step at a time, and yields the data we need to visualize its process. This rewrite is great because it’s unintrusive - there’s almost no chance the conversion will affect the logic of the function.

Now let’s put drawGraphFromArray and our new insertionSort Generator function together in a requestAnimationFrame render loop.

// code from above ...

const randomArr = Array(50).fill(0).map(Math.random);
const sortGenerator = insertionSort(randomArr);

function renderLoop() {
    const yieldedArray = sortGenerator.next().value;

    drawGraphFromArray(yieldedArray);

    requestAnimationFrame(renderLoop);
}
renderLoop();

resulting in our finished animation:

In the final animation above, we see the bar graph go from a jagged mess to a beautiful staircase. To achieve this, we ask our insertion sort to operate at one step per render loop with .next(). requestAnimationFrame makes sure our render loop runs at 60 frames per second, the perfect speed for a smooth animation.

Insertion sort is a simple example of what we can do...

This article was originally published on my blog http://elliot.website/a/?Visualizing%20Process%20with%20ES6%20Generators. Check it out to see some bonus content about creative coding using generators.

Thanks for reading. What's a creative way you've used generator function?