Last month I launched two open source projects on GitHub. A few days later, my Front-End Checklist was showing more than 6,000 stars (17,000 as of writing). And I got 600 stars for my Resources-Front-End-Beginner project!
It was unexpected for me to receive such support coming from so many people around the globe: USA, Brazil, China, Japan, France, Canada, Spain, Mauritius, Japan, Portugal... Even now, I still can’t believe how many pull requests I received with changes and corrections these last days.
For so long I received gifts from the open source world. Now I felt it was finally time for me to give back everything I have learned, and to help others.
As a professional Front-End manager, I spend my time teaching and encouraging others to learn and practice. I regularly share interesting content and useful tools on the Front-End Dev Mauritius group on Facebook. But I never planned that the Front-End Checklist will become a worldwide project.
I’ve seen some Front-End checklists over the past year on the web:
Some of them helped me years ago when I wanted to improve my Front-End knowledge, but most of them were just “not enough.”
Two years ago, I decided to start writing my own checklist based on my experiences. That checklist became way more important when I started to manage Front-End teams in France and Mauritius. Based on questions and usual mistakes from the teams, the content kept improving.
When I needed to teach someone how to become a better Front-End developer, I always had in mind that checklist that I started to work on. The document which started with a simple personal need became an ambitious tool for my team.
Then I started to feel the need to share it with more people.
A month ago I decided to put a first version on GitHub. And… at that moment, everything started to happen fast… really fast.
On 18 October, I published the first version of my Front-End Checklist. I went to see all members of my team and I asked them to put a star 😀 on the repository. They don’t really have the habit to star projects on Github, I had to encourage them to do so 😂.
A few hours later, watching an episode of Hawaii Five-O with my wife, I opened my GitHub repository on my iPad. I was shocked to find that in only few hours, I had already received 700 stars.
I was not able to understand why and where these stars were coming from. (At that time, I didn’t know about the Insights > Traffic section on GitHub.)
I hadn’t even published any tweet about the Github repository. The next day, I published on my Twitter account: just few likes and retweets about the checklist. Nothing that may explain, where everyone was coming from.
Check the new Front-End Checklist! https://t.co/Jyo14k3YMa #FrontEnd #checklist #html #javascript #Web
I then started to validate pull requests and answer some logged issues. I was feeling so grateful for that unimaginable support. Even working daily with international websites, I forgot sometimes the power of Internet. (Or it’s maybe I’m living in a small island far from everything 😂.)
Next day, I received on Twitter a message from Product Hunt:
@thedaviddias FYI, you've been added as a maker of Front End Checklist on @ProductHunt https://t.co/iteil8U9Am h/t @steedmonteiro 🙌
Without really taking time to think, I opened my Illustrator and designed a logo to put on the page. I kept it basic, inspired by the logo of Front-End Coders, a future NGO I’ll be launching soon officially.
Since then, I received in less than one week 40 pull requests, was published on Codrops for my 2 lists in their Collective #359, on the Panda Weekly Newsletter #130 and #131, Hacker news, Reddit (multiple times), NewsCenter.io, La Ferme du Web and more.
Translation in Japanese, Spanish, Chinese, Korean, Portuguese and Vietnamese were done in less than 2 weeks!
The list is positioned first on Google for the words “Front-End Checklist”. Some landing pages on Github have the checklist on first position (Front-End Development, Checklist, Guidelines).
I discovered more recently that the project was on top of the trending feed on GitHub with more than 6,000 stars in less than a week (on 27 October 2017).
I’m a big fan of “Awesome”, the curated list of awesome lists created first by Sindre Sorhus. But some lists are colossal and I found myself sometimes struggling to find what I want. I’m not sure if it’s because the amount of links or the absence of information attached to each link.
This is why I decided to add emoticons in my two lists. I usually don’t use them too often, but in that case I found interesting to add more of these to have more information about the content of my links.
As mentionned in the introduction of the Front-End Checklist, I used:
I also used 3 images (High, medium, low) to integrate different levels of priorities. I didn’t find any emoticon that could replace these images easily.
On my list of resources for Front-End Beginners, for example, I decided to indicate free and paid tutorials. It’s easier to have these type of informations before you click on any link. People can directly focus on what they prefer.
I use daily applications like Cloud Outliner Pro and MindNode to create new lists for my personal and professional life (and Todoist). I can’t imagine doing a complex task without a set of items into a list.
When it comes to sharing documentation or code, today, there’s no other place I like more than Github. Last week I decided I needed to put my work in a place where people can easily access and participate.
This kind of project is meant to be used and perfected by experiences and different points of view. Because Front-End development is always moving, evolving, it’s not always simple to stay on track on everything. Collaborative projects, where people can participate are for me the best way to have constantly updated tools.
I regularly meet young developers and people who want to become Front-End developer. Even on my YouTube channel, I receive lot of questions and requests. The first advice I give to them is to start coding and put their work on Github. It’s a way for them to show their interests to their friends, a future recruiter and to the world.
Don’t hesitate, everything you do, related to coding and web, take time to present it correctly on an README file and click “push”!
By the time I wrote this article I was already working on a small open-source web app... Today, you can already access the Front-End Checklist App online!
Due to many requests, I’m already working on an NPM module which will probably be used by a future website. It was not in my initial plans but when I saw so many people asking for, I couldn’t refuse.
I have much more to share! I’m working on other lists that may be as good as the Front-End Checklist… Well, I hope! 😃
How my open source project earned 6,000 stars on GitHub in just 5 days was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
A Modern Professional Learner's Toolkit for 2018 based on the Top 100 Tools for Personal & Professional Learning 2017 list. Continue Reading →
The post A Modern Learner’s Toolkit appeared first on E-Learning Curve Blog.
When I was looking for a new apartment to rent, I started to wonder: is there a data-driven decision making strategy for choosing a rental? Is there a month when the rent is lowest so I can save money when I start my lease?
To tackle this question, I used Zillow’s public data here. I analyzed their one-bedroom rental data from January, 2011 to September, 2017 for the top 100 US cities ranked by size.
The short answer is YES. You can save from $1000 to $2000 if you pick the right month to start renting in certain cities. By simply fitting a linear regression model using time and month to estimate rent, I found some interesting seasonality patterns for a few cities.
Methodology:
On the high level, rent = trend + seasonality. I fit a linear regression model for each city to breakdown trend and seasonality (using a cycle of 12 months).
Model: estimated rent(for a specific month)=t+t²+m1+m2+m3+…+m12
Variables: t and t² are continuous variables to estimate trend; t is the count of months from the beginning month in a city. I added t² to adjust for quadratic trend, and you’ll see some clear curves in the plot of Philadelphia below.
m1, m2, … , m12 are binary variables (0 or 1) that indicate to which month one data point (rent) belongs. Each rent data point can only be assigned one of the monthly variable (as 1). The rest will be 0.
After fitting the model above for all cities, I counted how many months’ coefficients were statistically significantly higher than the month estimated to have the lowest rent. I considered cities with a count ≥3 to have a potentially large seasonality effect.
Then I examined the the overall model fitting to filter out cities with a lot of noise, and came up with a final list of the six most representative cities. You can find my code here.
Now I’m going to show you these cities so you can see the sweetest month for you to start renting. I plotted the simulated rent against the actual rent below. You can see the pure seasonal difference (adjusted by each city’s trend) for each month on the lower right corner. Here’s how to read the plots:
Black line: actual rent data
Green line: simulated rent by regression model given month and year
Green bar plot on the right corner: pure seasonal effect estimated by model
Grey line: estimated trend by regression model
Seasonal gap: highest rent minus lowest rent (the difference estimated between the highest and lowest point from the regression model without trend effect)
Numerical labels: represent the months estimated to have highest (red) and lowest (blue) rent
You’ll definitely save money if you start renting on a “low” month in these cities.
If you start renting in June, you’ll save about $2484 a year (207*12) compared to starting a lease in November. The grey line shows a slight trend in Boston, but it’s not very significant compared to the strong seasonal factor.
2. Minneapolis
There is a slight upward trend, but the seasonality effect is more significant than the trend. Your yearly savings, if renting from December, can be as high as $1896 (158*12). In reality, this number is likely to be slightly lower, because the upward trend tends to shrink the difference a bit.
3. Philadelphia
After the regression model’s adjustment for the curve-shaped trend, the estimated yearly saving on rent is $1404 (117*12). This number is greater during the period with a downward trend: you can see that the distance between January and May’s rent is stretched further prior to 2014. The estimated savings are smaller when the overall rent increased during recent years.
4. Chicago
The overall trend in Chicago is actually the opposite of Philadelphia’s — it went up and then down. But the seasonality effect is still significant after adjusting for trend. The estimated yearly saving is $1248 (104*12). If the downward trend continues, the saving will be greater — the rent distance between November and April is stretched further as plotted in recent years.
5. Columbus
There is a noticeable upward trend in Columbus’s rent, but the seasonality effect is also quite significant. The estimated yearly savings are smaller after adjusting the pure seasonal gap ($89) by the upward trend, so you’d save around $720 (60*12). But you should still consider starting your lease in November and avoiding August.
6. Woodbridge
If you start renting in December, you’ll save about $948 (79*12) a year compared to renting from July. The trend isn’t very significant here, so it’s still seasonality that drives the rent price in Woodbridge.
What about Seattle, the city where I live?
The seasonality effect also exists in Seattle, and it shows significance in the regression model. However, the trend is so big that the seasonality almost doesn’t matter.
Even so, understanding the seasonality for cities like Seattle can be helpful. While you might not able to negotiate the rent down that much in a less busy season, you could ask that the application fee be waived or something like that.
My current apartment waived mine when I started my lease in January — December has the lowest rent, followed by January. But they might not offer this perk in the busiest months with higher rents, like May and June.
Another city where the trend outweighs the seasonality is Omaha.
Knowing your city’s seasonality in rent can help you save thousands if you know the pattern. I did my analysis and plots using R, but you can simply plot your city’s data in Excel if you just want to see if there are any noticeable trend and seasonality. Using open source data to hack your life decisions and save money is actually pretty simple.
Say you are offered a few different options for the length of your lease. Usually it’s nine months to 18 months. Do you know what’s the best length to choose when you sign your lease? There is actually another trick to save money when you pick the duration, and I’ll show you the trick and the math behind it in my next post.
Share this with friends who might find it useful!
*Follow My Facebook page Zhen_Data*
How to analyze seasonality and trends to save money on your apartment lease. was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
Four years ago, I read a quote that would change my life forever.
I don’t remeber the surrounding circumstances, but the sun was blazing hot and I was on the results page of a Google search.
A famous Pablo Picasso quote popped up, and for the next few weeks I was completely lost in it.
Good artists copy; great artists steal
— Pablo Picasso
As multiple questions kept my mind spinning, I had to read more about who Pablo was.
Pablo Picasso was an artist considered one of the most influential and greatest of the 20th century. At this point, I knew he was no failure going around talking trash.
I went on about my life, but that quote never left me.
Years after, I had become an astute follower of the “steal” philosophy. It was so ingrained into my subconscious that I thought I would someday write a New York Times bestseller on the subject.
I applied the rule to nearly everything I did.
For example, I spent hours re-writing several codepens (built by others) by hand, all in a bid to learn something by stealing. Earlier this year, I saw Dan Abramov talk about something similar.
Discovered a new trick for understanding a new codebase. Put it all in one file by hand.
I wasn’t crazy after all.
The steal rule appears to be a general rule for mastery.
In his book, Peak: Secrets from the new science of expertise, Anders Ericsson talks about the feedback loop and how essential it is to mastery. In fact, this was the same technique Benjamin Franklin used to write incredible books. He was arguably one of the best American writers of his time.
This mindset and learning method led me to attempt to recreate the Medium clap effect.
The Medium clap was designed and built by people with at least five times the smarts as I have. But this was not the first time I recreated other people’s stuff. The Medium clap was just one of many such projects.
I’ve always found the Medium clap to be so satisfying. Many times I’ve clapped after the 50 mark just to feel that satisfying animation.
Building the Medium clap was an interesting experiment. The goal wasn't to create an exact clone, just something that worked like it.
For content, I used good ol’ HTML and some SVG. I got a clap icon from the Noun Project.
I opened up the clap icon in Illustrator and edited it to my heart’s content. I then optimized via SVGOMG.
I needed Javascript for Interactivity. So, I built the clap with vanillaJS and then forked it to rebuild via ReactJS.
For animations, I chose LegoMushroom’s mo.js. It seemed to be the best for recreating the Medium clap animations. Mo.js is a pretty interesting animation library with a declarative API. I find it to be very beginner friendly, too.
I wasn’t particularly sure where to start. I had some experience with SVG, but didn't have a lot of experience with mo.js.
At this time there wasn’t any “working” Medium clap on codepen. There was nothing to learn there.
So I stole again.
“There must be something online I can learn from,” I said to myself. After a couple failed searches I found something.
Mary Lou’s Codrops is one hell of a resource for practical frontend stuff. I searched and found some animated icons there.
The icons were nothing like the Medium clap, but there was certainly something to learn there.
You know what I did, right?
I built the codrops animated icons from the ground up. I copied the entire codebase by hand.
This gave me a lot of perspective, and I knew how to go about the Medium clap afterwards.
Other than building the codrops animated icons, I didn't have substantial experience with mo.js
That wasn’t a big deal. I had always been excited by the prospect of learning something new faster, and I had developed a system for learning stuff fast.
In 2012, Scott Young completed all 33 courses in MIT’s fabled computer science curriculum, from Linear Algebra to Theory of Computation, in less than one year. He quickly became my inspiration.
This MIT curriculum was supposed to be a four-year curriculum, but somehow he managed to systematically tame it in under 12 months.
I believe in ultra learning. It is such an important skill in today’s economy.
So, what was the plan?
First off, I needed coverage. Coverage around the mo.js terrain. Like Scott says, you can’t plan an attack if you don’t have a map of the terrain.
First, I skimmed through the official mo.js tutorials. I skipped some, to be honest. I saw a youtube video where Sarah Drasner explained how the mo.js library worked. I watch the video at 2X speed. I also read Sarah’s book, SVG Animations. There was a chapter dedicated to the mo.js library.
I read very fast.
All I needed at this point was coverage on how the library worked and what was possible with it.
After these, I moved on to putting my knowledge to work. It was time to build the Medium clap.
After spending a lot of time on the animations, I ended up getting it right. Something that didn’t suck.
I got stuck at some points. I made mistakes, and even spent a few days tweaking stuff. But yeah, I got it to work.
I believe in continuously challenging myself. Pushing myself just beyond what I think I know or can do.
This was just another experiment in that regard.
I wouldn't say so.
On the 11th of October, the pen was picked, and went on to be viewed by over 2,000 people.
Picked pen 😊😊 https://t.co/XbYcoSyO19
I gave a talk at the ReactJS Summit, Lagos, on SVG and Microinteractions. There, I talked about micro interactions in the context of ReactJS apps, and got to show how to build the Medium clap effect.
@OhansEmmanuel is "demoing" 😄 on how to replicate @Medium clapping 👏 effects in #ReactJS. It's really cool 🔥🔥🔥#ReactSummit2017
— @_ooade
I have come to find a new love for micro interactions, and I believe they are the little giants that make a great product.
In all, it was an interesting and fruitful experiment. I don’t regret it. Not at all.
Do I plan on recreating some more ambitious projects? Hell yeah!
But hey, that’s a talk for another day :)
Keep building, keep coding!
How I (re)built the Medium clap effect — and what I got out of the experiment. was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
I posted just 2 months ago about Foxhound and how I found it pretty cool, but also curious that it was one of very few themes around that combine the WordPress JSON API and React, even though they seem like a perfect natural fit. Like a headless CMS, almost.
Since then, a few more things have crossed my desk of people doing more with this idea and combination.
Maxime Laboissonniere wrote Strapping React.js on a WordPress Backend: WP REST API Example:
I'll use WordPress as a backend, and WordPress REST API to feed data into a simple React e-commerce SPA:
- Creating products with the WP Advanced Custom Fields plugin
- Mapping custom fields to JSON payload
- Consuming the JSON REST API with React
- Rendering products in our store
Perhaps more directly usable, Postlight have put out a Starter Kit. Gina Trapani:
People who publish on the web love WordPress. Engineers love React. With some research, configuration, and trial and error, you can have both — but we’d like to save you the work.
WordPress + React is a post from CSS-Tricks
I’m 15, and I recently signed up for the Global Hackathon by Product Hunt. It runs for the month of November and there are 7,950 people participating from around the world 😲. Crazy!
From what I’ve seen in my 3 years as a student programmer, developers love hackathons. They’re an opportunity for product makers meet up, drink Red Bulls, and stay up all night coding.
It’s kind of like a triathlon for developers, who often go for days with minimal sleep. It’s a hard-fought race to the finish (if you even manage to finish). And it’s a chance to compete under pressure.
Shortly after I registered for the month-long event, I realized that competing in this hackathon is similar to entering a real triathlon. Just like in a regular triathlon, there are 3 stages, which all require a lot of skill and endurance:
I’ve already built something that started out as an idea. It’s called Christopher Bot, a Facebook Messenger bot that helps high school students remember their homework, and it’s been written about here and here and here. It also got acquired! But, you can read about that in my other Medium story here.
Before choosing to work on Christopher Bot, I had lots of ideas for products to build. My dad and I talked about how some ideas catch on, and some don’t. The ideas that catch on always seem to solve a problem.
If enough people have a problem and your product solves it well, and you can find a way to share your solution with those people, it has a good chance of succeeding.
I followed that advice when I chose to work on a homework bot. Students often forget what homework they’re assigned during the day, so I needed to build something that would stop people from forgetting their assignments. Christopher Bot was born.
I’m using that same advice in the Product Hunt hackathon.
I needed to find a problem. And in that problem, there would be a solution.
But where to begin?
In the Product Hunt competition, there are a bunch of existing platforms you can build for: Google Assistant, Slack, Blockchain, Artificial Intelligence and Augmented Reality. You don’t have to build for any of them, but some cool prizes are awarded within these specific categories.
Seeing these options actually made things easier for me. It narrowed down the list of possible problems to solve. All I had to do was find a problem in one of these categories.
I’m not yet familiar with blockchain technology… or AR or AI. So that made things even easier. Google Assistant is cool and could be interesting to develop for, but it turns out I’ve spent a fair bit of time using Slack.
I think Slack is pretty awesome and I’ve tried out a bunch of Slack apps. So I decided to build something in the Slack category.
At first, I thought about building something that would remind you about all your mentions in public channels — because once you click on a channel with a notification for you, the notification disappears and you have to respond right away or you might forget that you were mentioned.
But then came some bad news. My dad (who likes to talk these things through with me) experiences this notification problem, but he showed me that Slack already has a built-in solution.
You can mark important messages where you’re mentioned as “unread”, and you can even tell Slack bot to remind you about an important message after a specific period of time.
So it was back to the drawing board for me. ☹️
During the same conversation where I found out that bit of disappointing news, I also noticed that there’s no easy way to DM multiple people at the same time.
Was this even a real problem? It turns out (based on some quick Google searches) that people have asked about how to do this in Slack — and even in products that compete with Slack.
If you’re part of a big team and you want to ask multiple people the same question, but you don’t want everyone in a channel (or in a group DM) to see their responses, there’s no easy way to do it in Slack.
I checked hundreds of existing apps in the Slack app directory — and couldn’t find anything to solve this particular problem. But I found that the most popular slack apps are the ones that solved other problems for teams… another reminder that I needed to work on solving a real problem.
For example, getting everyone on your team to vote on something (like where to go for lunch) is a pain. So the people behind Simplepoll decided to solve that problem by enabling someone on a Slack team to easily create a quick poll, ask their team to vote, collect the responses, and count up the votes.
They found a problem common to many teams and built a nice simple solution. Which is exactly what I wanted to do.
My hackathon project is an idea that’s based on a real problem for Slack teams…
The problem: You want to ask multiple people the same question but you don’t want the entire team — or even a portion of the team — to see the question OR the responses. You can’t use a group DM or public channel… because everyone will see what you wrote, and see the responses (unless people are instructed to respond privately in a DM). It’s not very ideal.
Another less than ideal solution is to go down the list of team members and create a new DM, one after the other, by pasting the same message for each person. It’s so tedious that I think most people wouldn’t even bother.
So my entry for this hackathon is called MultiDM, a very simple Slack app that gives you and your team the ability to DM multiple people at the same time — using a single message, sent from any channel.
(Swim stage finished!)
Let’s say you think of an important HR-related question you want to ask 5 people on your team. And let’s say you’re already in the #general channel.
From the channel, you would just type “/multidm @john @jane @henry @samantha @jake I need your birthdate for HR — can you please let me know ASAP?”
Nobody will see the message you typed into #general. Instead, each of the 5 team members will receive a normal-looking DM from you — which they can respond to normally, and you’ll receive their answers without anyone else seeing the answers or even knowing that you asked multiple people the same question.
So that’s it. Next up is the long, difficult cycling stage. 🚴🏼
If you’re interested, you can sign up to be one of the first to try MultiDM.
Thanks for reading about my process for choosing a product idea. Most ideas aren’t successful because they don’t solve a real problem. People use products that fix a problem.
So for your next product (or hackathon idea), first find a problem, and then go build something to solve it!
How a hackathon is kind of like a real-life triathlon — but with more caffeine was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
Sweat is running down my face. I’m staring down a blank sublime text document. What on earth am I doing? My hands are resting above the keyboard of my MacBook pro.
There is enough friction to cuddle each of the keyboard buttons my fingers are resting on.
It’s like apologizing to them for not using them yet.
It’s late at night, and I’ve decided to jump in head first, creating my own app using React and Firebase.
How, I don’t know.
I only know that I’m going to do it, no matter what my imposter syndrome has to say about it.
I have made the decision.
My fingers move. The keyboard hives a sigh of relief in the form of a satisfying click sound.
I’m doing it!
Despair, my old friend. Late nights have been a recurring theme over the past week.
If anyone hacked my webcam, I would pity them.
They’d see a wide-eyed, tired, obsessive and wild programmer staring at the screen in an intent manner.
Alas, my compulsive behavior does not allow me to go to bed before every single bug is resolved.
Not a very healthy trait for a programmer, but a trait all the same.
The Ajax requests I put into my application are silently taunting me.
Every failed one yelling — “You’re an idiot”.
Ok, they are not so silent after all.
At this point, I’m at war.
And you don’t sleep while you’re at war.
The fight continues.
VICTORY. The enemy is subdued.
I wielded mighty Javascript Promises and beat them into submission.
Now I’m the one yelling at the Ajax requests. But instead of silently yelling, I’m actually yelling — “Haha, you’re working”.
Again, it’s late.
My girlfriend is not happy.
Being a gracious winner is overrated.
I refactored and broke the entire App. FML!
StackOverflow and various tutorial sites on the internet have become my second home.
I managed to fix the app.
The app looks like trash. Like super trash, like what a toddler would create, if a toddler could code.
Imagine a toddlers drawing, that is my App. I need CSS.
I cringe. It’s time to prepare. Prepare for frustration. Hours and hours of frustration.
I am not excited.
The App looks good!
I’m excited.
I realize my desktop layout will never work on mobile.
I decide to create a different mobile website based on some of the components I already have.
I decide to trash the entire visual direction of my website. My mobile site looks NOTHING like my desktop site.
For the past 5 days I’ve been on a brilliant coding high.
Splitting and reusing components. Resulting in a great mobile site that looks miles better than the desktop.
Sure, CSS did cause some frustration.
Yet, when you’re on top of the rainbow dancing to Bob Marley, not even CSS can bring you down.
It’s 6 AM. I’ve been working all night. I’m going to press the magic button. I’m launching it!
I’m tired, but there is no sleep to be had.
Instead I’m going to sit and watch Google Analytics for the rest of the day. The world is going to LOVE my product right?
My brilliant launch strategy is to create one Facebook post. I created the post in a crowded entrepreneurship forum.
One user.
Two users.
Three users.
It’s working!
I have 50 users, great success.
All users are going inactive. There is no activity on the website. Bounce rate is above 80%. I’m crying in the shower. Beer might also be there. And to top it off, it’s my birthday.
I decide to improve the app. First order of business is to improve the visuals of the desktop version to match the mobile.
I’m still crying, this time because I know I will have to do CSS again.
Success! Another enemy conquered. I forced CSS to bend to my will and create an appealing dashboard. Yes, it’s a love / hate relationship, I don’t deny it.
I decide to improve the landing page. Ugh, more CSS.
I made it out… I didn’t think I would. I decided to experiment with CSS transform. Rotating, scaling, translating. My head is spinning. I can’t even…
So tired.
I’m going to wake up tomorrow and discover that this is all a dream, aren’t I? If so, please don’t give me any more dreams like this. I can’t take it.
I slept for three days. It wasn’t a dream. The App looks good. I am happy.
It’s live: https://cryptodasher.com
This is a comical representation of my experience developing CryptoDasher. An App for tracking and storing your cryptocurrency information. It may be slightly exaggerated, but it’s all true.
Trial by Fire — How to Forge a Programmer was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
DeviceHive is an IoT platform which has plenty of different components. The Grafana plugin is one of them. This plugin can gather data from a DeviceHive server and display it with different dashboards using the very popular tool — Grafana. This article explains how to create a Grafana dashboard with DeviceHive. As an example, this uses the ESP8266 chip analog pin to visualise the voltage on it.
To display anything on a dashboard we need data. In terms of a DeviceHive server, data can be provided via ‘commands’ and ‘notifications’. Commands are typically used to deliver any messages to a device which the device should execute while ‘notifications’ are the opposite, devices notify their subscribers about certain events. ‘Commands’ and ‘notifications’ are basically simple JSON messages.
Both of these two entities can be used to plot graphs, display static text, a gauge, table or any other Grafana components. For this article we will generate notifications using special DeviceHive firmware for the ESP8266 chip. This firmware allows the chip to connect directly to a DeviceHive server using its protocol and has plenty of documented commands which can be issued from the server side.
The binaries for the DeviceHive firmware are available here. Download the latest version and flash this firmware to your chip. The release archive contains documentation on how to do that, but if you have a ‘nodemcu’-like board you just need to connect the board via a microUSB cable to your computer and run the ‘esp-flasher’ util from the release archive for your operating system and wait until it flashes the board. Having flashed the board, there is a need to configure the chip which Wi-Fi network, DeviceHive server, and credential it should use. There are two ways to do that: using a posix-like terminal with the ‘esp-terminal’ util or wirelessly as described here.
There is a free playground service, which can be used for absolutely free to try a DeviceHive server. After your chip is connected to your server or playground, go to the server admin panel, find your ESP8266 device in the device list and issue the ‘adc/int’ command with the parameters ‘{“0”: 500}’.
This command causes the esp8266 to report every 500ms the voltage on ADC input #0(the only ESP8266 has). After switching to ‘notifications’ there should be screen like:
That is the voltage on the chip’s input pin. And this kind of data is suitable for us to display with Grafana: notifications contain data (parameters in our case), notifications come continuously, and all DeviceHive’s notifications always have a timestamp. Having an analogue sensor connected to this pin it is possible to display this data with Grafana.
Grafana can be used as a local service or as a hosted service. To install Grafana locally, please, refer to the “Official documentation. Grafana installation”.
You can find how to install plugins in the “Official documentation. Plugin installation”.
To install DeviceHive datasource via grafana-cli you can use the following command:
$ grafana-cli plugins install devicehive-devicehive-datasource
If you want to install the plugin manually, you should perform the following steps:
Prerequisites, these packages should be installed:
Also you should have permissions to copy data to the Plugins folder (you could set it in grafana.ini in Paths->plugins).
After installation you will be able to see the DeviceHive datasource plugin in the installed plugins list (look at the picture below).
To add DeviceHive datasource, you should perform the following steps:
Look at the picture below:
To configure the DeviceHive datasource you should fill on the following fields:
Server URL (is the path to the DeviceHive WebSocket server. For the playground this is ws://playground.devicehive.com/api/websocket)
Device ID (unique identifier of the DeviceHive device)
Login/Password or AccessToken — credentials to pass authentication
Also, you are able to specify the RefreshToken for auto refreshing the AccessToken
On the picture below you can observe the configuration workflow:
After adding and configuring a DeviceHive datasource, it should exist in the datasource list as in the picture below:
To create a new dashboard you should just click on the “New” button in the sidebar panel as shown in the picture below:
In this article we will show examples on the Graph panel, so, click on the Graph button:
After that you will be able to see line chart on your dashboard:
Notification and commands are DeviceHive entities:
Command: represents a message dispatched by clients for devices
Notification: represents a message dispatched by devices for clients
By default, a Notification or Command message provides the field named “parameters” in which a user can pass their own data.
At the start of this article we configured the ESP8266 device to send notifications with data that represents the state on analogue pin#0 of the chip. In the picture below you are able to observe how to configure the Grafana graph panel to make it show the data on the line chart:
Annotations provide a way to mark points on the graph with rich events. When you hover over an annotation you can get an event description and event tags. The text field can include links to other systems with more detail.
More information about annotations you can find by following this link.
The picture below shows how to configure annotations powered by a DeviceHive datasource.
After clicking on the “Add converter” button you will be able to select a converter.
A converter is the simple function that transforms a value in some way.
For now, DeviceHive datasources support the following types of converters:
An example of this functionality is shown in the picture below.
Grafana is a perfect tool to visualise data. It is very flexible and provides many different features to make visualisation in a way thay you like. Grafana can use many data sources from a wide range of software solutions and DeviceHive is one of them. The sample which we described in this article is very simple. Using these principles it is possible to create more advanced graphs and we hope it will be helpful for you. Using Grafana and DeviceHive you can build your own IoT visualisation solutions and moreover you can modify both projects as you wish since Grafana and DeviceHive are open source software.
Written by collaboration with Igor Trambovetskiy, Senior Developer at DataArt.
How to run Grafana with DeviceHive was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
The last few weeks in Uncertainty Wednesday, with the exception of my net neutrality post, we have been looking at the relationship between sample data and distributions. Today is a bit of a recap so that we know where we are. One of the reasons for writing this series is that in the past I have found that it is super easy to get into lots of detail on mechanics and in the process lose sight of how everything hangs together.
So now is a good time to remind ourselves of the fundamental framework that I laid out early on: we have observations that provide us with signals about an underlying reality. Uncertainty arises because of limitations on how much we can learn about the reality from the observations. We looked at both limitations on the observations and limitations on explanations.
In the posts on samples and how they behave we have been working mostly in the opposite direction. That is we assumed we had perfect knowledge of the underlying reality. For instance, in the first post we assumed we had a fair dice that produced each number from 1 to 6 with exactly probability 1/6. In a later post we assumed we had a perfectly Cauchy distributed process. In each case we then proceeded to produce observations samples *from* that assumption.
Sometimes people call this the study of probability and reserve the term statistics for going the opposite direction, the one we are usually interested in, i.e. from the observations to improved knowledge about the underlying reality. Another term that you will hear in this context is “inference.” We are trying to infer something about reality from the data .
What then should be the key takeaway about inference from the last few weeks? That for some realities we can learn a lot from even relatively small samples, while for others that is not possible. Making this statement more precise will be a big part of Uncertainty Wednesday going forward. But for now you may have an immediate allergic reaction to the implied circularity of the situation. We are trying to learn about reality from observations but we don’t know how much we can learn unless we make assumptions about which reality we are dealing with. Welcome to uncertainty.
How do we cut this circularity? We do so only over time through better explanations. Explanations connect our observations to the reality. We start with a pretty bad explanation, which results in poor inference and a cloudy view of reality. We will then often use that view of reality to make predictions and compare those to future observations (possibly from experiments). Discrepancies arise, which lead us to consider different explanations. Some of those will emerge as better. They make better predictions. They fit better with subsequent observations.
This is why explanations are central to understanding uncertainty (and central to all of science). Too often, however, treatments of uncertainty make all sorts of implicit assumptions. For instance, assumptions of normality or at a minimum of thin tails abound (when we saw that fat tails behave wildly differently). Even when the distribution assumptions are explicit, they are often not related to a specific explanation.
It is quite frequent requirement to pass parameters to event handlers of custom React components. There are several ways to achieve this with ES6 depending on weather we need reference to the event or not.
We can define the event handler and bind it to this using JavaScript’s Function.prototype.bind() function.
If we need to pass custom parameters, then we can simply pass the parameters to the bind call. The SyntheticEvent will be passed as second parameter to the handler.
A bind call function in a JSX prop like above will create a brand new function on every single render. This is bad for performance, as it will result in the garbage collector being invoked way more than is necessary. It may also cause unnecessary re-renders if a brand new function is passed as a prop to a component that uses reference equality check on the prop to determine if it should update.
To avoid creating a brand new function on every single render, we can bind the function in the constructor.
Now, we need not to bind the function while specifying the event handler on line 13.
Calling bind every time is annoying. To avoid calling bind we can use ES6 arrow function which binds the function with this automatically.
We can also pass additional parameters to event handlers.
The problem with both above syntax is that a different callback instance is created each time the component is rendered, same as with the bind function.
To avoid creating a brand new callback instance on every render, we can use property initializer syntax to correctly bind callbacks.
To pass parameters to event handlers while using property initializer syntax, we need to use currying.
Provided all the different approaches above, using the arrow function with currying is the most efficient and cleaner way to define event handlers that accepts user defined parameters.
I would love to hear your comments, suggestions or questions on above approaches.
ReactJS - Parameterized Event Handlers was originally published in freeCodeCamp on Medium, where people are continuing the conversation by highlighting and responding to this story.
https://www.webdesignerdepot.com/2017/11/ultimate-ux-design-guide-to-saas-on-boarding-part-4-first-login/
A screenshot of the Front-End Checklist repository (numbers are already outdated since I finished writing that article)
700 stars on Github in only few hours
Front-End checklist and Front-End beginners essential logos
Insights for the Front-End Checklist on 23 October 2017
The Front-End Checklist is trending on Github!
The Front-End Checklist use emoticons to add more informations for each rule
The list of resources for Front-End Beginners also use emoticons to add some additional informations.
The 
Life happened. I never got to write the book :(
SVG Created by Luis Durazo from the 
The codrops animated icons were inspired by this shot by 
Example configurations for the animations powered by mo.js
https://finch.io/
http://www.pixelmator.com/blog/2017/11/29/pixelmator-pro-now-available-on-the-mac-app-store/
