From 04380313ecf3e0ecc55e7939cb4b957b74c04ae2 Mon Sep 17 00:00:00 2001 From: bmen Date: Thu, 8 Oct 2020 21:41:01 +0200 Subject: [PATCH] Theme portfolyou installiert --- .gitignore | 12 +- Gemfile | 4 + _config.yml | 96 ++++++++ _data/other-skills.yml | 7 + _data/programming-skills.yml | 11 + _data/social-media.yml | 92 ++++++++ _data/timeline.yml | 17 ++ ...2015-09-25-how-to-undo-your-git-failure.md | 8 + _posts/2016-02-09-what-is-version-control.md | 43 ++++ ...7-do-not-go-gentle-into-that-good-night.md | 40 ++++ _posts/2016-07-23-a-better-hello-world.md | 51 ++++ _posts/2017-01-01-github-flow.md | 67 ++++++ ...ns-after-eleven-years-in-silicon-valley.md | 47 ++++ .../2018-12-01-what-the-heck-is-a-callback.md | 142 +++++++++++ _posts/2019-02-15-learn-react-js.md | 223 ++++++++++++++++++ _posts/2019-02-20-digital-minimalism.md | 58 +++++ _projects/(1) PlaceHolder Project.md | 7 + _projects/(2) Awesome Project.md | 20 ++ _projects/(3) Empty Project.md | 7 + _projects/(4) VVG on GitHub.md | 7 + _projects/(5) The Fabulous.md | 7 + _projects/(6) Dummy Project.md | 7 + pages/404.html | 6 + pages/about.md | 20 ++ pages/blog.html | 9 + pages/index.md | 6 + pages/projects.html | 11 + pages/search.json | 15 ++ pages/tags.html | 7 + 29 files changed, 1046 insertions(+), 1 deletion(-) create mode 100644 Gemfile create mode 100644 _config.yml create mode 100644 _data/other-skills.yml create mode 100644 _data/programming-skills.yml create mode 100644 _data/social-media.yml create mode 100644 _data/timeline.yml create mode 100644 _posts/2015-09-25-how-to-undo-your-git-failure.md create mode 100644 _posts/2016-02-09-what-is-version-control.md create mode 100644 _posts/2016-04-17-do-not-go-gentle-into-that-good-night.md create mode 100644 _posts/2016-07-23-a-better-hello-world.md create mode 100644 _posts/2017-01-01-github-flow.md create mode 100644 _posts/2018-05-09-four-lessons-after-eleven-years-in-silicon-valley.md create mode 100644 _posts/2018-12-01-what-the-heck-is-a-callback.md create mode 100644 _posts/2019-02-15-learn-react-js.md create mode 100644 _posts/2019-02-20-digital-minimalism.md create mode 100644 _projects/(1) PlaceHolder Project.md create mode 100644 _projects/(2) Awesome Project.md create mode 100644 _projects/(3) Empty Project.md create mode 100644 _projects/(4) VVG on GitHub.md create mode 100644 _projects/(5) The Fabulous.md create mode 100644 _projects/(6) Dummy Project.md create mode 100644 pages/404.html create mode 100644 pages/about.md create mode 100644 pages/blog.html create mode 100644 pages/index.md create mode 100644 pages/projects.html create mode 100644 pages/search.json create mode 100644 pages/tags.html diff --git a/.gitignore b/.gitignore index 773419a..590d024 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,12 @@ +# Local Site Directories _site/ -.jekyll-cache/ \ No newline at end of file +.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..1498e64 --- /dev/null +++ b/Gemfile @@ -0,0 +1,4 @@ +source "https://rubygems.org" + +gem "github-pages", group: :jekyll_plugins +gem 'wdm', '>= 0.1.0' if Gem.win_platform? \ No newline at end of file diff --git a/_config.yml b/_config.yml new file mode 100644 index 0000000..77f8a6a --- /dev/null +++ b/_config.yml @@ -0,0 +1,96 @@ +### Site Settings ### +title : portfolYOU +description : >- + I turn coffee :coffee: into code, + use tabs over spaces + and never broke production. +baseurl : "/" # Change to empty quotes if you are hosting your site at .github.io directly +repository : YoussefRaafatNasry/portfolYOU # Change to /.github.io (or remove it if you don't need remote projects) +remote_theme : YoussefRaafatNasry/portfolYOU + + +### 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 : Bastian Menningen + image : https://i.imgur.com/uyDNQnn.jpg + behance : your_username +# dribbble : your_username + email : username@domain.com + facebook : your_username + github : your_username +# gitlab : your_username +# instagram : your_username +# kaggle : your_username + linkedin : your_username + medium : your_username +# soundcloud : your_username +# spotify : your_username +# stackoverflow : your_user_id +# tumblr : your_username.tumblr.com +# twitch : your_username + twitter : your_username +# vimeo : your_username +# youtube : your_channel_name + + +### Posts ### +permalink: /blog/:title + + +### Collections ### +collections: + projects: + output: true + permalink: /projects/:name + elements: # For Documentation Only + output: true # For Documentation Only + + +### Disqus ### +disqus: your-short-name-disqus # Your website Shortname on disqus + + +### Analytics ### +analytics: + enabled: false # Set true to enable analytics + google: + tracking_id: your-google-tracking-id + + +### 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: false # 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..fdc17fe --- /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: dark \ No newline at end of file diff --git a/_data/social-media.yml b/_data/social-media.yml new file mode 100644 index 0000000..b723737 --- /dev/null +++ b/_data/social-media.yml @@ -0,0 +1,92 @@ +# 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 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/_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..44847a2 --- /dev/null +++ b/_posts/2015-09-25-how-to-undo-your-git-failure.md @@ -0,0 +1,8 @@ +--- +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 +--- \ 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..fe3f7a8 --- /dev/null +++ b/_posts/2016-02-09-what-is-version-control.md @@ -0,0 +1,43 @@ +--- +title: What is version control? +tags: [Version Control] +style: fill +color: secondary +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/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 `