diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..590d024 --- /dev/null +++ b/.gitignore @@ -0,0 +1,12 @@ +# Local Site Directories +_site/ +.sass-cache/ +.jekyll-cache/ +.jekyll-metadata + +# Ruby Gems +.bundle +Gemfile.lock + +# Log Files +*.log \ No newline at end of file diff --git a/Gemfile b/Gemfile new file mode 100644 index 0000000..77106cb --- /dev/null +++ b/Gemfile @@ -0,0 +1,5 @@ +source "https://rubygems.org" + +gem "github-pages", group: :jekyll_plugins +gem 'wdm', '>= 0.1.0' if Gem.win_platform? +gem "webrick", "~> 1.8" diff --git a/_config.yml b/_config.yml new file mode 100644 index 0000000..38f0053 --- /dev/null +++ b/_config.yml @@ -0,0 +1,108 @@ +### Site Settings ### +title : Loïc (nockawa) Baumann's Blog +description : >- + Programming and stuffs. +baseurl : "" # Change to empty quotes if you are hosting your site at .github.io directly +repository : nockawa/nockawa.github.io # Change to /.github.io (or remove it if you don't need remote projects) +remote_theme : YoussefRaafatNasry/portfolYOU +open_new_tab : false # Opens external URLs in new tab (works for posts, projects and navbar only) + + +### Plugins ### +plugins: + - jemoji + + +### Navbar Settings ### +nav_exclude: # The following paths are excluded from navbar + - pages/tags.html + - pages/404.html + - pages/index.md + - documentation/partials/** # For Documentation Only + + +### Author Info ### +author: + name : Loïc Baumann + image : https://avatars.githubusercontent.com/u/48723305?s=100 +# behance : your_username +# dribbble : your_username +# email : username@domain.com +# facebook : your_username + github : nockawa +# gitlab : your_username +# instagram : your_username +# kaggle : your_username + linkedin : loicbaumann +# medium : your_username +# soundcloud : your_username +# spotify : your_username +# stackoverflow : your_user_id +# tumblr : your_username.tumblr.com +# twitch : your_username + twitter : loicbaumann +# vimeo : your_username +# youtube : your_channel_name +# keybase : your_username + + +### Posts ### +permalink: /blog/:title + + +### Collections ### +collections: + projects: + output: true + permalink: /projects/:name + elements: # For Documentation Only + output: true # For Documentation Only + + +### Disqus ### +disqus: + shortname: nockawa # Your website Shortname on disqus + + +### Analytics ### +analytics: + enabled: true # Set true to enable analytics + google: + tracking_id: G-SWCM571Y7W + + +### Buy me a coffee ### +# See https://www.buymeacoffee.com/ +buymeacoffee: + enabled: false + username: your_username + color: "#007bff" + message: "Thank you for visiting." # Message to be displayed aside from the button for a few seconds. + description: "Support me on Buy me a coffee!" + + +### Defaults for collections ### +defaults: + - scope: + path: "" + type: "projects" + values: + layout: "page" + - scope: # For Documentation Only + path: "" # For Documentation Only + type: "elements" # For Documentation Only + values: # For Documentation Only + layout: "element" # For Documentation Only + - scope: + path: "" + type: "posts" + values: + comments: true # Set to true to enable disqus comments + + +### Exclude from processing ### +exclude: + - README.md + - CONTRIBUTING.md + - LICENSE + - "*.log" diff --git a/_data/other-skills.yml b/_data/other-skills.yml new file mode 100644 index 0000000..543d3bb --- /dev/null +++ b/_data/other-skills.yml @@ -0,0 +1,7 @@ +- name: Adobe Photoshop + percentage: 95 + color: info + +- name: Adobe Illustrator + percentage: 90 + color: success \ No newline at end of file diff --git a/_data/programming-skills.yml b/_data/programming-skills.yml new file mode 100644 index 0000000..b879a61 --- /dev/null +++ b/_data/programming-skills.yml @@ -0,0 +1,11 @@ +- name: HTML5/CSS3 + percentage: 90 + color: danger + +- name: Go + percentage: 80 + color: + +- name: Python + percentage: 70 + color: secondary \ No newline at end of file diff --git a/_data/social-media.yml b/_data/social-media.yml new file mode 100644 index 0000000..df26cff --- /dev/null +++ b/_data/social-media.yml @@ -0,0 +1,97 @@ +# Get Icons from : https://fontawesome.com/icons +# Get Colors from : https://brandcolors.net/ + +behance: + url : https://www.behance.net/ + icon : fab fa-behance + color : 1769ff + +dribbble: + url : https://dribbble.com/ + icon : fab fa-dribbble + color : 444444 + +email: + url : "mailto:" + icon : fas fa-envelope + color : db4437 + +facebook: + url : https://www.facebook.com/ + icon : fab fa-facebook + color : 3b5998 + +github: + url : https://www.github.com/ + icon : fab fa-github + color : 333333 + +gitlab: + url : https://www.gitlab.com/ + icon : fab fa-gitlab + color : fca326 + +instagram: + url : https://www.instagram.com/ + icon : fab fa-instagram + color : 405de6 + +kaggle: + url : https://www.kaggle.com/ + icon : fab fa-kaggle + color : 20beff + +linkedin: + url : https://www.linkedin.com/in/ + icon : fab fa-linkedin-in + color : 007bb5 + +medium: + url : https://medium.com/@ + icon : fab fa-medium + color : 00ab6c + +soundcloud: + url : https://www.soundcloud.com/ + icon : fab fa-soundcloud + color : ff8800 + +spotify: + url : https://open.spotify.com/user/ + icon : fab fa-spotify + color : 1db954 + +stackoverflow: + url : https://stackoverflow.com/u/ + icon : fab fa-stack-overflow + color : f48024 + +tumblr: + url : https:// + icon : fab fa-tumblr + color : 35465c + +twitch: + url : https://www.twitch.tv/ + icon : fab fa-twitch + color : 6441a5 + +twitter: + url : https://www.twitter.com/ + icon : fab fa-twitter + color : 1da1f2 + +vimeo: + url : https://www.vimeo.com/ + icon : fab fa-vimeo-v + color : 162221 + +youtube: + url : https://www.youtube.com/ + icon : fab fa-youtube + color : ff0000 + +keybase: + url : https://www.keybase.io/ + icon : fab fa-keybase + color : 66ccff \ No newline at end of file diff --git a/_data/timeline.yml b/_data/timeline.yml new file mode 100644 index 0000000..0efce11 --- /dev/null +++ b/_data/timeline.yml @@ -0,0 +1,17 @@ +- title: Student, Harvard CS + from: 2014 + to: 2018 + description: Lorem ipsum dolor sit amet, consectetur adipiscing elit, + sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. + Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris + nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in + reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. + +- title: Software Engineer, Google, UK + from: 2018 + to: present + description: Lorem ipsum dolor sit amet, consectetur adipiscing elit, + sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. + Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris + nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in + reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. \ No newline at end of file diff --git a/_elements/01-headers.html b/_elements/01-headers.html new file mode 100644 index 0000000..936e172 --- /dev/null +++ b/_elements/01-headers.html @@ -0,0 +1,9 @@ +--- +--- + +# H1 +## H2 +### H3 +#### H4 +##### H5 +###### H6 diff --git a/_elements/02-emphasis.html b/_elements/02-emphasis.html new file mode 100644 index 0000000..f565ad7 --- /dev/null +++ b/_elements/02-emphasis.html @@ -0,0 +1,7 @@ +--- +--- + +Emphasis, aka italics, with *asterisks* or _underscores_. +Strong emphasis, aka bold, with **asterisks** or __underscores__. +Combined emphasis with **asterisks and _underscores_**. +Strikethrough uses two tildes. ~~Scratch this.~~ diff --git a/_elements/03-highlight.html b/_elements/03-highlight.html new file mode 100644 index 0000000..21d3805 --- /dev/null +++ b/_elements/03-highlight.html @@ -0,0 +1,6 @@ +--- +--- + +{% raw %} +{% include elements/highlight.html text="I am highlighted text." %} +{% endraw %} diff --git a/_elements/04-blockquotes.html b/_elements/04-blockquotes.html new file mode 100644 index 0000000..2ae143b --- /dev/null +++ b/_elements/04-blockquotes.html @@ -0,0 +1,9 @@ +--- +--- + +> Blockquotes are very handy in email to emulate reply text. +> This line is part of the same quote. + +Quote break. + +> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep writing to make sure this is long enough to actually wrap for everyone. Oh, you can *put* **Markdown** into a blockquote. diff --git a/_elements/05-links.html b/_elements/05-links.html new file mode 100644 index 0000000..e57f24d --- /dev/null +++ b/_elements/05-links.html @@ -0,0 +1,4 @@ +--- +--- + +[I'm a link](https://www.google.com) diff --git a/_elements/06-line-breaks.html b/_elements/06-line-breaks.html new file mode 100644 index 0000000..e0b2c4c --- /dev/null +++ b/_elements/06-line-breaks.html @@ -0,0 +1,9 @@ +--- +--- + +Here's a line for us to start with. + +This line is separated from the one above by two newlines, so it will be a *separate paragraph*. + +This line is also a separate paragraph, but... +This line is only separated by a single newline, so it's a separate line in the *same paragraph*. diff --git a/_elements/07-horizontal-rule.html b/_elements/07-horizontal-rule.html new file mode 100644 index 0000000..979f1eb --- /dev/null +++ b/_elements/07-horizontal-rule.html @@ -0,0 +1,10 @@ +--- +tips: + - Three or more Underscores, Hyphens or Asterisks... +--- + +___ + +--- + +*** diff --git a/_elements/08-code.html b/_elements/08-code.html new file mode 100644 index 0000000..0eccd6a --- /dev/null +++ b/_elements/08-code.html @@ -0,0 +1,9 @@ +--- +--- + +Inline `code` has `back-ticks around` it. + +``` +s = "Code Block Test"; +print s; +``` diff --git a/_elements/09-syntax-highlighting.html b/_elements/09-syntax-highlighting.html new file mode 100644 index 0000000..728c31e --- /dev/null +++ b/_elements/09-syntax-highlighting.html @@ -0,0 +1,12 @@ +--- +--- + +```javascript +var s = "This is JavaScript syntax highlighting"; +alert(s); +``` + +```python +s = "But this is Python syntax highlighting" +print s +``` diff --git a/_elements/10-github-gists.html b/_elements/10-github-gists.html new file mode 100644 index 0000000..4fbca45 --- /dev/null +++ b/_elements/10-github-gists.html @@ -0,0 +1,7 @@ +--- +tips: + - To include a **single file** just add the file name after the **gist ID**:
+ `{% gist 3c466b... Hello%20World.java %}` or `{% gist 3c466b... hello.py %}` +--- + +{% gist 3c466bc3c32c4ae5c9b36d1266b913d8 %} diff --git a/_elements/11-buttons.html b/_elements/11-buttons.html new file mode 100644 index 0000000..e9e584a --- /dev/null +++ b/_elements/11-buttons.html @@ -0,0 +1,15 @@ +--- +tips: + - 'To **center** your buttons, surround it with the following HTML tag:
+ `

{% include ... %}

`' + - 'Know more about buttons from + [Bootstrap Buttons](https://getbootstrap.com/docs/4.1/components/buttons/)' +--- + +{% raw %} +{% include elements/button.html link="https://github.com" text="GitHub" style="primary" size="sm" %} +{% include elements/button.html link="https://github.com" text="GitHub" %} +{% include elements/button.html link="https://github.com" text="GitHub" style="outline-dark" size="lg" %} +{% include elements/button.html link="https://github.com" text="GitHub" block=true %} +{% endraw %} + diff --git a/_elements/12-ordered-list.html b/_elements/12-ordered-list.html new file mode 100644 index 0000000..6d8afb0 --- /dev/null +++ b/_elements/12-ordered-list.html @@ -0,0 +1,10 @@ +--- +--- + +1. First ordered list item +2. Another item + * Unordered sub-list. +1. Actual numbers don't matter, just that it's a number + 1. Ordered sub-list +4. And another item. + Some text that should be aligned with the above item. diff --git a/_elements/13-unordered-list.html b/_elements/13-unordered-list.html new file mode 100644 index 0000000..9f981df --- /dev/null +++ b/_elements/13-unordered-list.html @@ -0,0 +1,6 @@ +--- +--- + +* Unordered list can use asterisks +- Or minuses ++ Or pluses diff --git a/_elements/14-list-group.html b/_elements/14-list-group.html new file mode 100644 index 0000000..60c3fbf --- /dev/null +++ b/_elements/14-list-group.html @@ -0,0 +1,10 @@ +--- +--- + +{% raw %} +{% capture list_items %} +Google,https://www.google.com +GitHub,https://www.github.com +{% endcapture %} +{% include elements/list.html title="Websites" %} +{% endraw %} diff --git a/_elements/15-table-of-contents.html b/_elements/15-table-of-contents.html new file mode 100644 index 0000000..09f458b --- /dev/null +++ b/_elements/15-table-of-contents.html @@ -0,0 +1,11 @@ +--- +--- + +{% raw %} +{% capture list_items %} +Headers +Emphasis +List +{% endcapture %} +{% include elements/list.html title="Table of Contents" type="toc" %} +{% endraw %} diff --git a/_elements/16-images.html b/_elements/16-images.html new file mode 100644 index 0000000..aba157b --- /dev/null +++ b/_elements/16-images.html @@ -0,0 +1,4 @@ +--- +--- + +![alt text](https://bit.ly/2TOsM7B "Building Image") diff --git a/_elements/17-figures.html b/_elements/17-figures.html new file mode 100644 index 0000000..ade23a9 --- /dev/null +++ b/_elements/17-figures.html @@ -0,0 +1,6 @@ +--- +--- + +{% raw %} +{% include elements/figure.html image="https://bit.ly/2N69TKO" caption="The Ocean" %} +{% endraw %} diff --git a/_elements/18-carousel.html b/_elements/18-carousel.html new file mode 100644 index 0000000..2688e1c --- /dev/null +++ b/_elements/18-carousel.html @@ -0,0 +1,10 @@ +--- +--- + +{% raw %} +{% capture carousel_images %} +https://bit.ly/2BBbVhc +https://bit.ly/2DOtxXB +{% endcapture %} +{% include elements/carousel.html %} +{% endraw %} diff --git a/_elements/19-videos.html b/_elements/19-videos.html new file mode 100644 index 0000000..4d55028 --- /dev/null +++ b/_elements/19-videos.html @@ -0,0 +1,11 @@ +--- +tips: + - '**How to get a YouTube video ID?**
+ The video ID is located in the URL of the video page, right after the `v=` URL parameter.
+ In this case, the URL of the video is: `https://www.youtube.com/watch?v=aZNbUITN-mA`.
+ Therefore, the ID of the video is `aZNbUITN-mA`.' +--- + +{% raw %} +{% include elements/video.html id="aZNbUITN-mA" %} +{% endraw %} diff --git a/_elements/20-tables.html b/_elements/20-tables.html new file mode 100644 index 0000000..084a1dc --- /dev/null +++ b/_elements/20-tables.html @@ -0,0 +1,8 @@ +--- +--- + +| Left | Center | Right | +| ------------- |:-------------:| -------:| +| col 3 is | right-aligned | $160000 | +| col 2 is | centered | $12 | +| **Use** | `Markdown` | $1 | diff --git a/_elements/21-task-list.html b/_elements/21-task-list.html new file mode 100644 index 0000000..8abbb56 --- /dev/null +++ b/_elements/21-task-list.html @@ -0,0 +1,6 @@ +--- +--- + +* [x] A Task List +* [ ] With some items that +* [ ] Are not done yet \ No newline at end of file diff --git a/_posts/2015-09-25-how-to-undo-your-git-failure.md b/_posts/2015-09-25-how-to-undo-your-git-failure.md new file mode 100644 index 0000000..d8a53b5 --- /dev/null +++ b/_posts/2015-09-25-how-to-undo-your-git-failure.md @@ -0,0 +1,9 @@ +--- +title: How to undo your git failure? +tags: [External Post, Git] +style: fill +color: warning +description: Using `git reflog` and `git reset` to save your code. +external_url: https://blog.usejournal.com/how-to-undo-your-git-failure-b76e31ecac74 +comments: true +--- \ No newline at end of file diff --git a/_posts/2016-02-09-what-is-version-control.md b/_posts/2016-02-09-what-is-version-control.md new file mode 100644 index 0000000..9fcb586 --- /dev/null +++ b/_posts/2016-02-09-what-is-version-control.md @@ -0,0 +1,44 @@ +--- +title: What is version control? +tags: [Version Control] +style: fill +color: secondary +comments: true +description: Benefits of version control and version control systems. +--- + +Source: [atlassian](https://www.atlassian.com/git/tutorials/what-is-version-control) + +![](https://wac-cdn.atlassian.com/dam/jcr:34e935dd-3108-40ef-bb3d-9ed01d977d6d/hero.svg?cdnVersion=la) + +## Benefits of version control + +Version control systems are a category of software tools that help a software team manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members. + +For almost all software projects, the source code is like the crown jewels - a precious asset whose value must be protected. For most software teams, the source code is a repository of the invaluable knowledge and understanding about the problem domain that the developers have collected and refined through careful effort. Version control protects source code from both catastrophe and the casual degradation of human error and unintended consequences. + +Software developers working in teams are continually writing new source code and changing existing source code. The code for a project, app or software component is typically organized in a folder structure or "file tree". One developer on the team may be working on a new feature while another developer fixes an unrelated bug by changing code, each developer may make their changes in several parts of the file tree. + +Version control helps teams solve these kinds of problems, tracking every individual change by each contributor and helping prevent concurrent work from conflicting. Changes made in one part of the software can be incompatible with those made by another developer working at the same time. This problem should be discovered and solved in an orderly manner without blocking the work of the rest of the team. Further, in all software development, any change can introduce new bugs on its own and new software can't be trusted until it's tested. So testing and development proceed together until a new version is ready. + +Good version control software supports a developer's preferred workflow without imposing one particular way of working. Ideally it also works on any platform, rather than dictate what operating system or tool chain developers must use. Great version control systems facilitate a smooth and continuous flow of changes to the code rather than the frustrating and clumsy mechanism of file locking - giving the green light to one developer at the expense of blocking the progress of others. + +Software teams that do not use any form of version control often run into problems like not knowing which changes that have been made are available to users or the creation of incompatible changes between two unrelated pieces of work that must then be painstakingly untangled and reworked. If you're a developer who has never used version control you may have added versions to your files, perhaps with suffixes like "final" or "latest" and then had to later deal with a new final version. Perhaps you've commented out code blocks because you want to disable certain functionality without deleting the code, fearing that there may be a use for it later. Version control is a way out of these problems. + +Version control software is an essential part of the every-day of the modern software team's professional practices. Individual software developers who are accustomed to working with a capable version control system in their teams typically recognize the incredible value version control also gives them even on small solo projects. Once accustomed to the powerful benefits of version control systems, many developers wouldn't consider working without it even for non-software projects. + +## Benefits of version control systems + +Developing software without using version control is risky, like not having backups. Version control can also enable developers to move faster and it allows software teams to preserve efficiency and agility as the team scales to include more developers. + +Version Control Systems (VCS) have seen great improvements over the past few decades and some are better than others. VCS are sometimes known as SCM (Source Code Management) tools or RCS (Revision Control System). One of the most popular VCS tools in use today is called Git. Git is a Distributed VCS, a category known as DVCS, more on that later. Like many of the most popular VCS systems available today, Git is free and open source. Regardless of what they are called, or which system is used, the primary benefits you should expect from version control are as follows. + +1. A complete long-term change history of every file. This means every change made by many individuals over the years. Changes include the creation and deletion of files as well as edits to their contents. Different VCS tools differ on how well they handle renaming and moving of files. This history should also include the author, date and written notes on the purpose of each change. Having the complete history enables going back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix problems in older versions of software. If the software is being actively worked on, almost everything can be considered an "older version" of the software. + +1. Branching and merging. Having team members work concurrently is a no-brainer, but even individuals working on their own can benefit from the ability to work on independent streams of changes. Creating a "branch" in VCS tools keeps multiple streams of work independent from each other while also providing the facility to merge that work back together, enabling developers to verify that the changes on each branch do not conflict. Many software teams adopt a practice of branching for each feature or perhaps branching for each release, or both. There are many different workflows that teams can choose from when they decide how to make use of branching and merging facilities in VCS. + +1. Traceability. Being able to trace each change made to the software and connect it to project management and bug tracking software such as Jira, and being able to annotate each change with a message describing the purpose and intent of the change can help not only with root cause analysis and other forensics. Having the annotated history of the code at your fingertips when you are reading the code, trying to understand what it is doing and why it is so designed can enable developers to make correct and harmonious changes that are in accord with the intended long-term design of the system. This can be especially important for working effectively with legacy code and is crucial in enabling developers to estimate future work with any accuracy. + +While it is possible to develop software without using any version control, doing so subjects the project to a huge risk that no professional team would be advised to accept. So the question is not whether to use version control but which version control system to use. + +There are many choices, but here we are going to focus on just one, Git. \ No newline at end of file diff --git a/_posts/2016-04-17-do-not-go-gentle-into-that-good-night.md b/_posts/2016-04-17-do-not-go-gentle-into-that-good-night.md new file mode 100644 index 0000000..e2bc9dc --- /dev/null +++ b/_posts/2016-04-17-do-not-go-gentle-into-that-good-night.md @@ -0,0 +1,40 @@ +--- +title: Do not go gentle into that good night +tags: [Poetry] +style: fill +color: light +description: +--- + +Do not go gentle into that good night, +Old age should burn and rave at close of day; +Rage, rage against the dying of the light. + + +Though wise men at their end know dark is right, +Because their words had forked no lightning they +Do not go gentle into that good night. + + +Good men, the last wave by, crying how bright +Their frail deeds might have danced in a green bay, +Rage, rage against the dying of the light. + + +Wild men who caught and sang the sun in flight, +And learn, too late, they grieved it on its way, +Do not go gentle into that good night. + + +Grave men, near death, who see with blinding sight +Blind eyes could blaze like meteors and be gay, +Rage, rage against the dying of the light. + + +And you, my father, there on the sad height, +Curse, bless, me now with your fierce tears, I pray. +Do not go gentle into that good night. +Rage, rage against the dying of the light. + + +— _Dylan Thomas, 1914 - 1953_ \ No newline at end of file diff --git a/_posts/2016-07-23-a-better-hello-world.md b/_posts/2016-07-23-a-better-hello-world.md new file mode 100644 index 0000000..a300c13 --- /dev/null +++ b/_posts/2016-07-23-a-better-hello-world.md @@ -0,0 +1,51 @@ +--- +title: A better Hello World +tags: [Software Development] +style: fill +color: dark +description: A different “hello world” to demonstrate language features better. +--- + +Source: [RICO STA. CRUZ](https://ricostacruz.com/til/a-better-hello-world) + +The “Hello world” program is usually the first introduction to any programming language. It looks like this in the C programming language: + +```c +/* hello.c */ +#import + +int main(int argc, char *argv[]) { + printf("Hello, world!"); + return 0; +} +``` + +It demonstrates the minimum amount you need to write a C program. In more modern languages however, this example isn’t as useful anymore. Here’s the same example in Python: + +```python +# hello.py +print "Hello, world!" +``` + +## A better hello world + +In today’s world of more succint programming languages, we need a different “hello world” to demonstrate language features better. Here’s what I propose: + +``` +// hello.js +function getGreeting (name) { + return `Hello, ${name}!` +} + +const message = getGreeting('world') +console.log(message) +``` + +This simple example demonstrates a few more things than printing strings: + +- How to write a function with an argument +- Returning values from functions +- How to use variables +- The naming convention for functions (camelCase versus snake_case) +- String concatenation +- Comments \ No newline at end of file diff --git a/_posts/2017-01-01-github-flow.md b/_posts/2017-01-01-github-flow.md new file mode 100644 index 0000000..25c756f --- /dev/null +++ b/_posts/2017-01-01-github-flow.md @@ -0,0 +1,67 @@ +--- +title: GitHub Flow +tags: [GitHub, Workflow] +style: fill +color: primary +description: GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly. This guide explains how and why GitHub Flow works. +--- + +Source: [GitHub Guides](https://guides.github.com/introduction/flow/) + +## Create a branch + +When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. + +When you create a branch in your project, you're creating an environment where you can try out new ideas. Changes you make on a branch don't affect the `master` branch, so you're free to experiment and commit changes, safe in the knowledge that your branch won't be merged until it's ready to be reviewed by someone you're collaborating with. + +#### ProTip + +Branching is a core concept in Git, and the entire GitHub flow is based upon it. There's only one rule: anything in the `master` branch is always deployable. + +Because of this, it's extremely important that your new branch is created off of master when working on a feature or a fix. Your branch name should be descriptive (e.g., `refactor-authentication`, `user-content-cache-key`, `make-retina-avatars`), so that others can see what is being worked on. + +## Add commits + +Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch. + +Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction. + +#### ProTip + +Commit messages are important, especially since Git tracks your changes and then displays them as commits once they're pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback. + +## Open a Pull Request + +Pull Requests initiate discussion about your commits. Because they're tightly integrated with the underlying Git repository, anyone can see exactly what changes would be merged if they accept your request. + +You can open a Pull Request at any point during the development process: when you have little or no code but want to share some screenshots or general ideas, when you're stuck and need help or advice, or when you're ready for someone to review your work. By using GitHub's @mention system in your Pull Request message, you can ask for feedback from specific people or teams, whether they're down the hall or ten time zones away. + +#### ProTip + +Pull Requests are useful for contributing to open source projects and for managing changes to shared repositories. If you're using a Fork & Pull Model, Pull Requests provide a way to notify project maintainers about the changes you'd like them to consider. If you're using a Shared Repository Model, Pull Requests help start code review and conversation about proposed changes before they're merged into the master branch. + +## Discuss and review your code + +Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation. + +You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view. + +#### ProTip + +Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting. + +## Deploy + +With GitHub, you can deploy from a branch for final testing in production before merging to master. + +Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production. + +## Merge + +Now that your changes have been verified in production, it is time to merge your code into the master branch. + +Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made. + +#### ProTip + +By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase `Closes #32` would close issue number 32 in the repository. \ No newline at end of file diff --git a/_posts/2018-05-09-four-lessons-after-eleven-years-in-silicon-valley.md b/_posts/2018-05-09-four-lessons-after-eleven-years-in-silicon-valley.md new file mode 100644 index 0000000..21c5880 --- /dev/null +++ b/_posts/2018-05-09-four-lessons-after-eleven-years-in-silicon-valley.md @@ -0,0 +1,47 @@ +--- +title: 4 Lessons After 11 Years in Silicon Valley +tags: +style: fill +color: success +description: On the realities of opportunity, success, reputation, and relationships in tech. +--- + +Source: [Ashley Mayer](https://medium.com/s/story/four-lessons-after-eleven-years-in-silicon-valley-d87507b7a4f6) + +Silicon Valley is a magical place with some strange norms—perhaps because companies, careers, and fortunes rise and fall with such astounding speed. Here are a few of the quirky, brutal, and hopefully useful lessons I learned during my 11 years living and working in the technology industry’s epicenter. + +## 1. There’s opportunity in what others undervalue + +There’s a rigid hierarchy of functions in Silicon Valley. At the top of the pyramid sit the entrepreneurs, the engineers, the venture capitalists. The closer you are to building or funding, the more respect you get—which probably makes sense. But when I began my career in tech, I wasn’t prepared for how little respect is left over for other functions: recruiting, HR, marketing, communications, etc. There’s an assumption that truly great products market themselves or that truly great companies are magnets for top talent. To work in these superfluous fields is either a sign that your company must compensate for its lack of greatness or that you’re but an intermediary for the inevitable. + +Of course, not everyone thinks like this. And that’s where the upside to this warped view comes in. At the company level, it’s quite clear you’ll need to out-innovate your competitors by building a better product. But what about the less obvious vectors for competition? With the benefit of hindsight, it’s easy to see where investments in culture have paid off exceptionally well (and where the lack thereof has halted otherwise unstoppable companies). In nascent industries—especially highly regulated ones—educating customers and stakeholders about your product and market may be as core to survival as the product itself. + +This opportunity for differentiation also exists at the individual level. It used to bother me that people made certain assumptions about me based on my profession. I craved validation from my peers and resented the stereotypes that came along with PR. But the longer I’ve been in this field, the more respect I have for how nuanced, impactful, and essential our work is, and consequently, I’m bothered less by other people’s projections. An unfortunate consequence of the hierarchy of functions is that it’s harder to attract top talent to the layers we undervalue, which hurts the industry as a whole. But, as an individual, it means that it’s probably more feasible to distinguish yourself as one of the top recruiters or marketers than it is to become a top engineer in a world where that is the ultimate prize. + +## 2. There’s nothing more dangerous early in your career than success + +One of our industry’s oft-repeated (and oft-abused) sayings is, “If you’re offered a seat on a rocket ship, you don’t ask what seat. You just get on.” It’s what Google’s then-CEO Eric Schmidt told Sheryl Sandberg to convince her to come onboard in 2001, and I’ve always appreciated the humility embedded in this perspective (for the seat-taker, that is). But we often fail to dwell on the inevitable follow-up question: If you took a seat on that rocket ship, and it was indeed a rocket ship, how do you know if you made any meaningful impact on its speed or trajectory? + +Success is one of the most dangerous things that can happen to you early in your career. When you’re on a so-called rocket ship, you’re likely drinking from the fire hose daily, making things up as you go along. If you’re given responsibilities that exceed your experience, you’re probably plagued by self-doubt. Then, at some point, if you’re lucky, the company you’ve helped build is declared a success. And those many bumps along the way are ironed out into a perfect narrative. Perhaps you’re even tempted to believe it. + +> Some reputations are built on much less than you would assume. + +In Silicon Valley, myths about people and companies tend to beat out carefully considered case studies. Maybe it’s because so much creation happens when companies are still private and therefore less observable. Maybe it’s because there are so many new and invisible forces at work (emerging technology trends, cultural and behavioral shifts) in a company’s meteoric rise that mythology is the only way we can make sense of it. Maybe it’s because we love a good story—and a good creation story most of all. + +It’s a balancing act to allow yourself pride in what you’ve helped accomplish without getting caught up in your own personal mythology. Be grateful for the tough times: They will keep you anchored during headier cycles. If you battle insecurity and anxiety on the regular (raises hand), find solace in the fact that you’re probably working harder than you would if you were capable of believing that it was your seat that made all the difference. + +## 3. Some reputations are built on surprisingly little + +This is going to seem random, but bear with me: In the 1999 rom-com Never Been Kissed, Drew Barrymore’s character, Josie, is a reporter who goes undercover as a high school student to write about the “cool” high school crowd. But there’s just one problem: She’s super uncool, so she can’t get anywhere near them. Then her naturally cool younger brother decides to relive his high school glory days and salvages her assignment by convincing the cool kids that Josie is, in fact, quite cool. “All you need is for one person to think you’re cool,” he tells her. “And you’re in.” + +Silicon Valley can feel a little like high school—in many ways, but especially when it comes to people’s reputations. I’m regularly shocked by how much just one person declaring someone a “rockstar” can open doors and even change the trajectory of a career. And if the person doing the declaring is particularly influential, other people will repeat their pronouncement as a given. The speed and opacity of startup trajectories make it impossible to really know how impactful someone was (how to separate the seat from the rocket ship), so personal endorsements carry a tremendous amount of weight. Which means that some reputations are built on much less than you would assume. + +This is troubling, especially because influential people tend to skew white and male, as do their networks, which only reinforces existing power structures. But it’s also an incredible opportunity to elevate deserving but underappreciated and underrepresented people—especially if you yourself are influential. I doubt many people know how much weight their words carry. + +Of course, if you’re not accustomed to wielding this power—or asking for it to be wielded on your behalf—it can feel pretty uncomfortable. Women in particular have a harder time transitioning from the personal and emotional to the transactional in their relationships. My female friends and I have discussed this extensively and have even experimented with a “favor swap” event where the whole point is to get transactional. Maybe this is what Lean In Circles should have been all along—lead with the favors, not the feelings. + +## 4. Your former co-workers are your rocks, so keep them close + +This one is simple, but important. We all know how critical it is to build strong relationships inside a company, but it wasn’t until I moved on from my first startup job that I realized how incredibly valuable co-worker relationships become after you leave. After years together in the trenches, former co-workers know your strengths and can call you on your bullshit. And once you’re no longer co-workers, all those pesky work-related complications and politics disappear. + +Your non-co-worker friends will of course cheer you on, but if you’re in a rut professionally or trying to figure out if you’re the one being difficult in a dysfunctional work relationship, no one can help you troubleshoot like your former colleagues. Same if you need a substantive ego boost. And because your relationship started in a work context, it’s also much easier to be transactional, whether that means asking for intros, references, funding, or feedback. \ No newline at end of file diff --git a/_posts/2018-12-01-what-the-heck-is-a-callback.md b/_posts/2018-12-01-what-the-heck-is-a-callback.md new file mode 100644 index 0000000..1123b0c --- /dev/null +++ b/_posts/2018-12-01-what-the-heck-is-a-callback.md @@ -0,0 +1,142 @@ +--- +title: What the heck is a Callback? +tags: [JavaScript, Nodejs, Web Development] +style: fill +color: danger +description: Learn and understand the basics of callbacks in just 6 minutes with easy examples. +--- + +Source: [Brandon Morelli](https://codeburst.io/javascript-what-the-heck-is-a-callback-aba4da2deced) + +![](https://cdn-images-1.medium.com/max/2000/1*pWGJIKats-zuumA3RQNEWQ.jpeg) + +## What is a Callback? + +**Simply put:** A callback is a function that is to be executed **after** another function has finished executing — hence the name ‘call back’. + +**More complexly put:** In JavaScript, functions are objects. Because of this, functions can take functions as arguments, and can be returned by other functions. Functions that do this are called **higher-order functions**. Any function that is passed as an argument is called a **callback function**. + +^ That’s a lot of words. Lets look at some examples to break this down a little more. + +## Why do we need Callbacks? + +For one very important reason — JavaScript is an event driven language. This means that instead of waiting for a response before moving on, JavaScript will keep executing while listening for other events. Lets look at a basic example: + +```javascript +function first(){ + console.log(1); +} +function second(){ + console.log(2); +} +first(); +second(); +``` + +As you would expect, the function `first` is executed first, and the function `second` is executed second — logging the following to the console: + +```javascript +// 1 +// 2 +``` + +All good so far. + +But what if function `first` contains some sort of code that can’t be executed immediately? For example, an API request where we have to send the request then wait for a response? To simulate this action, were going to use `setTimeout` which is a JavaScript function that calls a function after a set amount of time. We’ll delay our function for 500 milliseconds to simulate an API request. Our new code will look like this: + +```javascript +function first(){ + // Simulate a code delay + setTimeout( function(){ + console.log(1); + }, 500 ); +} +function second(){ + console.log(2); +} +first(); +second(); +``` + +It’s not important that you understand how `setTimeout()` works right now. All that matters is that you see we’ve moved our `console.log(1);` inside of our 500 millisecond delay. So what happens now when we invoke our functions? + +```javascript +first(); +second(); +// 2 +// 1 +``` + +Even though we invoked the `first()` function first, we logged out the result of that function after the `second()` function. + +It’s not that JavaScript didn’t execute our functions in the order we wanted it to, it’s instead that **JavaScript didn’t wait for a response from `first()` before moving on to execute `second()`**. + +So why show you this? Because you can’t just call one function after another and hope they execute in the right order. {% include elements/highlight.html text="Callbacks are a way to make sure certain code doesn’t execute until other code has already finished execution." %} + +## Create a Callback + +_Alright, enough talk, lets create a callback!_ + +First, open up your Chrome Developer Console (Windows: Ctrl + Shift + J)(Mac: Cmd + Option + J) and type the following function declaration into your console: + +```javascript +function doHomework(subject) { + alert(`Starting my ${subject} homework.`); +} +``` + +Above, we’ve created the function `doHomework` . Our function takes one variable, the subject that we are working on. Call your function by typing the following into your console: + +```javascript +doHomework('math'); +// Alerts: Starting my math homework. +``` + +Now lets add in our callback — as our last parameter in the `doHomework()` function we can pass in `callback`. The callback function is then defined in the second argument of our call to `doHomework()`. + +```javascript +function doHomework(subject, callback) { + alert(`Starting my ${subject} homework.`); + callback(); +} + +doHomework('math', function() { + alert('Finished my homework'); +}); +``` + +As you’ll see, if you type the above code into your console you will get two alerts back to back: Your ‘starting homework’ alert, followed by your ‘finished homework’ alert. + +But callback functions don’t always have to be defined in our function call. They can be defined elsewhere in our code like this: + +```javascript +function doHomework(subject, callback) { + alert(`Starting my ${subject} homework.`); + callback(); +} +function alertFinished(){ + alert('Finished my homework'); +} +doHomework('math', alertFinished); +``` + +This result of this example is exactly the same as the previous example, but the setup is a little different. As you can see, we’ve passed the `alertFinished` function definition as an argument during our `doHomework()` function call! + +## A real world example + +Last week I published an article on how to Create a Twitter Bot in 38 lines of code. The only reason the code in that article works is because of Twitters API. When you make requests to an API, you have to wait for the response before you can act on that response. This is a wonderful example of a real-world callback. Here’s what the request looks like: + +```javascript +T.get('search/tweets', params, function(err, data, response) { + if(!err){ + // This is where the magic will happen + } else { + console.log(err); + } +}) +``` + +- `T.get` simply means we are making a get request to Twitter +- There are three parameters in this request: `‘search/tweets’`, which is the route of our request, `params` which are our search parameters, and then an anonymous function which is our callback. + +A callback is important here because we need to wait for a response from the server before we can move forward in our code. We don’t know if our API request is going to be successful or not so after sending our parameters to search/tweets via a get request, we wait. Once Twitter responds, our callback function is invoked. Twitter will either send an `err` (error) object or a `response` object back to us. In our callback function we can use an `if()` statement to determine if our request was successful or not, and then act upon the new data accordingly. \ No newline at end of file diff --git a/_posts/2018-12-10-clean-coding.md b/_posts/2018-12-10-clean-coding.md new file mode 100644 index 0000000..2bc8bca --- /dev/null +++ b/_posts/2018-12-10-clean-coding.md @@ -0,0 +1,102 @@ +--- +title: Clean Coding +tags: [Software Development, Clean Code] +style: fill +color: info +description: These four “clean code” tips will dramatically improve your engineering team’s productivity +--- + +Source: [Jonathan Fulton](https://engineering.videoblocks.com/these-four-clean-code-tips-will-dramatically-improve-your-engineering-teams-productivity-b5bd121dd150) + +A few years ago at VideoBlocks we had a major code quality problem: “spaghetti” logic in most files, tons of duplication, no tests and more. Writing new features and even minor bug fixes required a couple of Tums at best and entire bottles of Pepto-Bismol and Scotch far too often. Our WTFs per minute were sky-high. + +{% include elements/figure.html image="https://cdn-images-1.medium.com/max/1600/1*J2mKSLBEp_jUbMtOWXTTjQ.png" caption="Several years ago we were definitely in the room on the right but we’ve moved a lot closer to the room on the left." %} + +Today, the overall quality of our codebases are significantly better thanks in large part to a deliberate effort to improve code quality. A couple ago when we identified the problem, we read Robert Martin’s Clean Code as a team and did our best to implement his recommendations and even introduced “clean code” as a core cultural tenant for the engineering team. I highly recommend doing both as you start scaling. Implementing “clean code” practices appropriately will double productivity in the long run (at a bare minimum) and significantly improve moral on the engineering team. Who wants to be in the room on the right given the choice? + +Out of all the ideas we implemented from Clean Code and other sources, five provided at least 80% of the gains in productivity and team happiness. + +1. **“If it isn’t tested, it’s broken”** + Write lots of tests, especially unit tests, or you’ll regret it. +1. **Choose meaningful names** + Use short and precise names for variables, classes, and functions. +1. **Classes and functions should be small and obey the Single Responsibility Principle (SRP)** + Functions should be no more than 4 lines and classes no more than 100 lines. Yep, you read that correctly. They should also do one and only one thing. +1. **Functions should have no side effects** + Side effects (e.g., modifying an input argument) are evil. Make sure not to have them in your code. Specify this explicitly in the function contracts where possible (e.g., pass in native types or objects that have no setters) + +Let’s walk through each one in detail so you can understand and start applying them in your day-to-day life on an engineering team. + +## 1. “If it isn’t tested, it’s broken” + +I started regularly repeating this sentence to our engineers as we encountered bugs that should’ve been caught by (nonexistent) tests. You too will prove the quote true again and again unless you build a culture of testing. Write a lot of tests, especially unit tests. Think very hard about integration tests and make sure you have a sufficient number in place to cover your core business functionality. Remember, if there’s not test coverage for a piece of code you’ll likely break it in the future without realizing it until your customers find the bug. + +Repeat “if it isn’t tested, it’s broken” to your team over and over until the message sinks in. Practice what you preach, whether you’re a brand new software engineer straight out of school or a grizzled veteran. + +## 2. Choose meaningful names + +> There are two hard problems in Computer Science: cache invalidation and naming things. + +You may have heard this quote before and it couldn’t be more relevant to your day-to-day life on an engineering team. If you and your team aren’t good at naming things in your code, it will become an unmaintainable nightmare and you won’t get anything done. You’ll lose your best developers and your company will soon go out of business. + +Seriously though, friends don’t let friends use bad variable names like data, foobar, or myNumber and they most certainly don’t let them name classes things like SomethingManager. Make sure your names are short and precise, but when in conflict favor precision. Strongly optimize around developer efficiency and make it easy to find files via “find by name” IDE shortcuts. Enforce good naming stringently with code reviews. + +## 3. Classes and functions should be small and obey the Single Responsibility Principle (SRP) + +Small and SRP go together like a chicken and an egg, a virtuous cycle of deliciousness. Let’s start with small. + +What does “small” mean for functions? No more than 4 lines of code. Yep, you read that correctly, 4 lines. You’re probably closing the tab right now but you really shouldn’t. It seems somewhat arbitrary and small and you’ve probably never written code like that in your life. However, 4-line functions force you to think hard and pick a lot of really good names for sub-functions that make your code self-documenting. Additionally, they mean you can’t use nested IF statements that force you to do mental gymnastics to understand all the code paths. + +Let’s walk through an example together. Node has an npm module called “build-url” which is used for doing exactly what it’s name suggests: it builds URLs. You can find the link to the source file we’re going to look at here. Below is the relevant code. + +{% gist 53b03db644353af05279f8fe3eea1a09 %} + +Notice that this function is 35 lines long. It’s not too hard to understand but it could be significantly easier to reason about if we apply our “small” principle to factor out helper functions. Here’s the updated and improved version. + +{% gist 167dc8833b9058eafc5cdebc3a2609a9 %} + +You’ll notice that while we didn’t adhere strictly to the 4 lines per function rule, we did create several functions that are relatively “small”. Each one does exactly one task that’s easy to understand based on it’s name. You could even unit test each of these smaller functions independently if you wanted, as opposed to only being able to test the one large buildUrl function. You may also notice that this methodology produces slightly more code, 55 lines instead of 35. That’s perfectly acceptable because those 55 lines are a lot more maintainable and easier to read the the 35 lines. + +How do you write code like this? I personally find it easiest to write the list of steps down that you need to accomplish the task you’re hoping to do. Each of these steps might be a good candidate for a sub/helper function. For instance, we could describe the buildUrl function as follows: + +1. Initialize our base url and options +1. Add the path (if any) +1. Add the query parameters (if any) +1. Add the hash (if any) + +Notice how each of these steps translates almost directly into a sub-function. Once you get in the habit, you’ll eventually write all of your code using this top-down approach where you create a list of steps, stub the functions, and continue recursively like this into each of the sub-functions creating a list of steps, stubbing, and so on. + +Moving on to our related concept, the Single Responsibility Principle. What does this mean? Quoting directly from Wikipedia: + +> The Single Responsibility Principle (SRP) is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. + +Robert Martin in Clean Code provides a parallel definition: + +> The SRP states that a class or module should one, and only one, reason to change. + +Let’s say we’re building a system that needs to a certain type of report and display it. A naive approach might be to build a single module/class that stores the report data as well as the logic for displaying the report. However, that violates SRP because there are two high level reasons to modify the class. First, if the report fields change, we’ll need to update it. Second, if the report visualization requirements change, we’ll need to update the class. Therefore instead of a single class to store both the data and the logic for rendering the data, we should split those concepts and areas of ownership into two different classes, say ReportData and ReportDataRenderer or something similar. + +## 4. Functions should have no side effects + +Side effects are truly evil and make it extremely difficult to create code without bugs. Check out the example below. Can you spot the side effect? + +{% gist 63706c9490634bc48f768051256dbdf1 %} + +The function as named is designed to look up a user by email/password combination, a standard operation for any web application. However, it also has a hidden side effect that you do not know about as the function consumer without reading the implementation code: it logs the user in, which creates a login token, adds it to the database, and sends a cookie back to our user with the value so they’re subsequently “logged in”. + +There are many things wrong with this. + +First, the function contract/interface is not easily understood without reading the implementation code. Even if the login side-effect is documented, though, it’s still not ideal. Engineers tend to use intellisense in modern IDEs so won’t think they need to read the documentation based on the simple function name. They’ll tend to use the function solely to fetch the user object, failing to realize that they’re adding a cookie to the request which can lead to all sorts of fun hard-to-find bugs. + +Second, testing the function is fairly challenging given all the dependencies. Verifying that you can look a user up by email/password requires mocking out an HTTP response as well as handling the writes to the login token table. + +Third, the tight coupling between user lookup and login inevitably won’t satisfy all use cases in the future, where you’ll likely need to look up a user or login a user independently. In other words, it’s not “future proof”. + +--- + +In summary, make sure to remember and apply these four “clean code” principles to dramatically improve your team’s productivity: + +1. **“If it isn’t tested, it’s broken”** +1. **Choose meaningful names** +1. **Classes and functions should be small and obey the Single Responsibility Principle (SRP)** +1. **Functions should have no side effects** \ No newline at end of file diff --git a/_posts/2019-02-15-learn-react-js.md b/_posts/2019-02-15-learn-react-js.md new file mode 100644 index 0000000..ceff686 --- /dev/null +++ b/_posts/2019-02-15-learn-react-js.md @@ -0,0 +1,223 @@ +--- +title: Learn React.js in 5 minutes +tags: [React, JavaScript, Web Development] +style: border +color: primary +description: A quick introduction to the popular JavaScript library. +--- + +Source: [freecodecamp](https://medium.freecodecamp.org/learn-react-js-in-5-minutes-526472d292f4) + +This tutorial will give you a basic understanding of React.js by building a very simple application. I’ll leave out everything which I don’t think is core. + +## The setup + +When getting started with React, you should use the simplest setup possible: an HTML file which imports the `React` and the `ReactDOM` libraries using script tags, like this: + +```html + + + + + + +
+ + + +``` + +We’ve also imported Babel, as React uses something called JSX to write markup. We’ll need to transform this JSX into plain JavaScript, so that the browser can understand it. + +There are more two things I want you to notice: + +1. The `
` with the id of `#root`. This is the entry point for our app. This is where our entire app will live. +1. The `