teleren/devto huggingface dataset:
MDX
Tags: markdown, jsx, react, javascript
Published: 2019-03-02 19:41:50

---
title: MDX
published: true
tags: Markdown, Jsx, react, javascript 
canonical_url: https://www.kahlillechelt.com/2018/06/15/mdx/
---

> [MDX](https://github.com/mdx-js/mdx) is a JSX in Markdown loader, parser, and renderer for ambitious projects. It combines the readability of Markdown with the expressivity of JSX. The best of both worlds.

If you configure MDX for your project you can do wild things like importing React components into your markdown file and use them in there.

```
import Graph from './components/graph'
## Here's a graph
<Graph />
```

And on the other hand you can import your MDX files into React components and use them as regular React components.

```
import React from 'react'
import Hello from '../hello.md'
export default () => <Hello />
```

Powerful stuff. If you are a developer building something with React or Next.js and you want to add content to the project, that’s a really nice way to do it. It feels kind of mind blowing once you use it.

MDX is a superset of the [CommonMark](http://commonmark.org/) specification that adds embedded JSX and the `import/export` syntax.

CommonMark was created by the people who built Discourse. They support Markdown on their platform and they needed a clear specification that handles certain edge cases. [The original specification by John Gruber](https://daringfireball.net/projects/markdown/syntax) was not specific enough. At first they wanted to call it [Standard Markdown](https://blog.codinghorror.com/standard-flavored-markdown/) but [Gruber threw a hissyfit, wrote an angry email](https://blog.codinghorror.com/standard-markdown-is-now-common-markdown/) and even talked about it on his podcast The Talkshow.

Discourse never sought to upset him or take anything away from him so they renamed it to CommonMark.

It’s great to see that things like MDX can be built quite safely and relatively easy because there is a Markdown specification.
Build a website in 3 minutes
Tags: github, firebase, website, terminal
Published: 2018-06-15 02:29:19

---
title: Build a website in 3 minutes
published: true
description: 
tags: 
- github
- firebase
- website
- terminal
---

{% youtube hLdsb3rnjXw %}

Build a website with terminal, nano, git, github, firebase.
Btw, all tools and services are free.
How to code
Tags: beginners, code, javascript, python
Published: 2018-06-15 02:25:16

---
title: How to code
published: true
description: Noob tips for noobies
tags: 
- beginners
- code
- javascript
- python
---

{% youtube alJK5Uo3Xa0 %}

TL;DR. Noob tips for noobies
DockerCon Day 3
Tags: docker, containers, kubernetes, security
Published: 2018-06-14 22:24:48

---
title: DockerCon Day 3
published: true
description: summary of day 3 at DockerCon2018
tags: docker, containers, Kubernetes, security
cover_image: https://thepracticaldev.s3.amazonaws.com/i/9dmzg13c78mx6y1ppzat.jpeg
---

I wrote up a summary of the morning session for Day 3 of #DockerCon18

https://vault.osninja.net/dockercon-day-3-part-1/
Deep Sea Adventure "Retrospective"
Tags: agile, scrum, teambuilding, games
Published: 2018-06-14 21:44:18

---
title: Deep Sea Adventure "Retrospective"
published: true
description: A little team-building exercise
tags: agile, scrum, team-building, games
---
![](https://thepracticaldev.s3.amazonaws.com/i/rsmrhrvbqlk5jazloycz.jpg)


As a change of pace for our sprint retrospective, I decided to try a little experiment using the "[Deep Sea Adventure](https://boardgamegeek.com/boardgame/169654/deep-sea-adventure) " game. In this little table-top game, each player is a diver trying to grab as much treasure as they can, being sure to make it back to the submarine before the oxygen supply runs out.

[![image](https://cf.geekdo-images.com/itemrep/img/SNl4Fn0XnbACeIyS8m3ni247GEM=/fit-in/246x300/pic3169827.png)](https://boardgamegeek.com/boardgame/169654/deep-sea-adventure)

## Game Play

We played four rounds. We varied a bit from the actual rules by returning all retrieved treasures back to the initial start configuration, so that each round was like the start of a new game.

First, we played one round of the game as it would normally be played, with every player for himself. This provided everyone a chance to get a feel for how the game works, and how the greedier you get, the faster you use up the available oxygen supply.

After that, we played three rounds in a cooperative mode, with the stated goal being to score as many total points as possible when adding our scores together. (Otherwise the rules and mechanics stayed the same.)

1. In the first round, no communication was allowed in terms of planning, hints, suggestions, complaints, etc.

1. We added a planning phase to the next round, spending a few minutes discussing what sort of strategy and tactics we would use to optimize our chances for a better score. Once we started playing though, inter-player communication was still a no-no.

3. In the final round, we opened up all communication channels, allowing us to not only tweak our initial strategy, but to discuss changes and adaptations at any point during the game.

## Results

While luck can play a critical role in this game at times, we managed to increase our total score each round; so in a very limited set of test data we proved that planning is better than no planning, and continual feedback and adjustment of plans are even better. 😉

If interested in learning more about the game, [this Youtube video](https://www.youtube.com/watch?v=KLxTglV4Zyg&t=1481s) begins with a rules explanation, then they play a full game (which only takes about 17 minutes).
CI, CD, automated tests?
Tags: discuss, test, continuousdelivery
Published: 2018-06-14 21:29:46

---
title: CI, CD, automated tests?
published: true
description: Get to know the state of the art in testing, integration, deployment
tags: discuss, test, continuous delivery 
---

Hey! I am really curious:
what is the state of the art in testing, integration, and deployment?

Do you have a comprehensive automated test suite? What kind of tests?

Do you practice Continuous Integration: all developers of your team integrate into the same branch at least daily?

Do you have a build pipeline and practice Continuous Delivery?

How did you start? What were the challenges? Where are you now?
Quick terminal tip
Tags: terminal, osx, productivity, programming
Published: 2018-06-14 21:26:20

---
title: Quick terminal tip
published: true
description: There is one small thing that made my life as a software developer a little better
tags: terminal, osx, productivity, programming
---

Originally posted on: https://mociun.xyz/quick-terminal-tip/

There is one small thing that made my life as a software developer a little better. And not many people seem to know about it.

The trick is hotkey terminal window. It is basically an additional terminal window that is always visible, and you can show/hide it using a keyboard shortcut.

![Additional window!](https://cdn-images-1.medium.com/max/1600/1*6Pq051EVu6ORgiZ323XYeg.gif)


This additional window seemed to be really handy as a code scratchpad or dedicated man window. It is so convenient that I sometimes use it as themain terminal.

I believe this feature should be available on most platforms. I personally use iTerm2 (Mac only, sorry) and it has this functionality built-in. In my case, the new window show/hide up after I press CTRL two times.

![Setup hotkey window in iTerm2
](https://cdn-images-1.medium.com/max/1600/1*d8_oE_voBZW5cnwPwFlnvA.png)

Originally posted at: [Medium](https://medium.com/the-runway/quick-tip-for-mac-keep-handy-additional-terminal-window-fe7bb7ab49eb)
Five Things Jr. Developers Need To Know
Published: 2018-06-14 21:10:00

---
title: Five Things Jr. Developers Need To Know
published: true
description: Being a Jr. Developer is a natural stage for everyone. We all start somewhere. Aimee Knight shares her essential tips for Jr. Developers everywhere. 
tags: 
---

Everyone is a Jr. Developer at some point. It's unavoidable. Nobody shows up on day one with all the answers. At some point, we all have to begin at the beginning. At some point you **will** be the new kid.

![a sign that says "begin"](https://thepracticaldev.s3.amazonaws.com/i/dietbq2ahal5mc82b18k.jpg)
<cite>Photo by Matt Long from [Flickr](https://www.flickr.com/photos/memorymotel/5412266176/in/photolist-9fghb5-csBPfJ-YAymUK-4K2Twy-228cxxy-B8dWd-WUfDjT-irJ6Sp-7eAemY-c8fBwA-7pMzoc-6c2Peq-8EdXXV-7yXaEC-ehSFRM-7xJAib-4YQmjA-HuKEVG-aCh5NA-7cuymw-cURb2N-7ezSeB-6G6Wre-dZFD5f-4ddHj9-6Hh2tG-9tg65Q-sweHhG-9xmNp1-ardmEa-6qxuKH-foNQQv-7kwKFP-46uhrw-9yqnAE-8MCxcZ-aF7zNJ-bss8tg-8NoZrm-SpjV7b-V4xGUJ-mDsUrK-3fKAmM-4Jnuyk-aiLQLw-qymdNL-7vecJC-6CfWSP-pzmVmE-7f8Kwy)

Being new is intimidating. It's hard to be in a new school, a new church or try to find a new new group of friends. Jr. Developers have the tough job of being new and not having nearly as much experience as everyone else. It's a **lot** for anyone to take on; and if that's you, take heart because we've all been there. 

I sat down with [Aimee Knight](https://twitter.com/aimee_knight) to talk about the essential things that Jr. Developers need to know. Aimee has spoken at conferences all over the world and has often shared her experience coming from a code bootcamp after making a career change later in life. I quite enjoyed this discussion, and I wish someone had shared these things with me when I was the new front-end developer on a highly skilled team of senior people. I had some rough days.

Check out this interview with Aimee. For more 5 Things videos, make sure you [subscribe to Channel 9 on YouTube](https://www.youtube.com/playlist?list=PLlrxD0HtieHgugDxYBujMFnvSveH4fgWN).

You can find Aimee on Twitter as [@Aimee_Knight](https://www.youtube.com/playlist?list=PLlrxD0HtieHgugDxYBujMFnvSveH4fgWN)

{% youtube PGF9HZQbiHc %}
Changelog: Announcing DEV Connect! (Beta)
Tags: meta, changelog
Published: 2018-06-14 19:42:31

---
title: Changelog: Announcing DEV Connect! (Beta)
published: true
description: 
tags: meta, changelog
cover_image: https://thepracticaldev.s3.amazonaws.com/i/j6uoap4enjxg8fme3udc.png
---

We're excited to announce a new part of the site called [DEV Connect](/connect). Spurred on by an interest from the community in this sort of thing, we've added a place for connecting and chatting with other community members.

It's a messaging section which many will find immediately useful, but we plan to progressively enhance with some really nice dev-oriented tools. Here is an (early beta) example of what you can do:

![](https://thepracticaldev.s3.amazonaws.com/i/brcv6dnr50btby7ivglh.gif)

Connect is live, but is very much still a **work in progress**. We plan on pairing these sorts of features with initiatives around mentorship, office hours, and all sorts of goodies. You are going to have a lot of fun with all of this.

We also expect that Connect will become a hub for interacting with the content of the broader platform. Consuming, creating and sharing DEV posts will be very native. This next feature is not live as I write this (but may be when you read this), but here's a quick shot from my local environment of what I'm talking about.

![](https://thepracticaldev.s3.amazonaws.com/i/hgbt3e9l5pxp634rf131.gif)

For now, you may open a channel with anyone you mutually follow. As DEV Connect evolves we'll make the configuration of who you can chat with available in finer detail, but the mutual-follow model is a pretty well established protocol for this sort of feature across the web.

We also have some group channels which are available to some members at the moment for testing. We will make those more accessible as we work out the details.

This is very much a beta feature, so things might be randomly broken, but we invite you to check it all out.

# [dev.to/connect](/connect)

Happy coding ❤️
Negotiating is hard.
Tags: podcast, career, discuss, negotiating
Published: 2018-06-14 18:38:16

---
title: Negotiating is hard.
published: true
description: It was a delight to chat about job offers and negotiating with Gloria Kimbwala and Jessica Rose!
tags: podcast, career, discuss, negotiating
---

# *Negotiating is hard.*

[![](https://thepracticaldev.s3.amazonaws.com/i/4s0txo46bfpjxc71m2cu.jpg
)](hyperurl.co/pursuitpod )
*Artist: [@NeonLanterns](https://twitter.com/NeonLanterns)*

I had a delightful conversation on [Pursuit Podcast](https://twitter.com/pursuitpod) with [Gloria Kimbwala](https://twitter.com/gkimbwala) and [Jessica Rose](https://twitter.com/jesslynnrose) about various aspects of job offers and negotiation tactics! 

Some examples of things besides your base salary you can negotiate for are...

- Signing bonus
- Relocation Assistance
- Vacation days
- Conference stipend
- Equity
- ... and a lot more

> ### What are your tips for job offer negotiations or things you think people should be aware of?

Check out the episode to learn more about the logistics of your job offer:
👉🏼 [hyperurl.co/pursuitpod](http://hyperurl.co/pursuitpod)

----

Definitely make sure to follow me on dev.to for more awesome content
✨https://dev.to/amycodes✨
Definition of Done (or not done)
Tags: agile, projectmanagement, scrum
Published: 2018-06-14 15:54:43

---
title: Definition of Done (or not done)
published: true
description: An introduction to the principle of DoD and its usage.
tags: agile, project management, scrum
---

As a developer and Scrum enthusiast, I am working daily on a self-organizing team. One of the parts of my daily agile work that I would give the most important is the principle of a "Definition of Done". I am currently reading a lot about agile development methods as well as design patterns and other architectural principles.

Why am I writing this article? Well, there are actually two reasons.
* I was reading a book and there were some thoughts about DoDs that I would not share and so I decided to write a post about my opinion about DoDs.
* Secondly, I was surprised when talking to some developers in an agile context (even Scrum) that they were not knowing what that is.

## What is a "Definition of Done"?

Basically, a DoD defines whether a certain ticket, user story or task is done. The DoD should be defined by the whole agile team<sup>1</sup>. Only defining those rules is not enough from my point of view. Actually, every team member should clearly understand the DoD and accept its content. Otherwise, there would be ignorance on that list. I do not think that it makes sense to have a DoD if you do not care about any quality assurance.

## Visibility of the DoD

There are two things that I would like to say about how to present the DoD.

1. The DoD should be visible within the office to every team member. (e.g. whiteboard, large print, ...)
2. The DoD should be available and visible within Planning and Refinement meetings.

## Content of a DoD

So now we are talking about what actually could be part of a DoD. All here listed elements are just proposals and contents that worked out for me in practical landscape.

### Acceptance Criteria

Every DoD should contain that all acceptance criteria of a ticket are fulfilled.

### Automated Testing

Every DoD should contain all needed test methods (e.g. unit, integration, acceptance, manual).

### Internationalization

If you are doing i18n then I would make it part of the DoD to ensure that everything is automatically translated.

### Review

All types of review should be done (e.g. functional review, code review).

## DoDs and Refactoring

I read that the process of refactoring (especially in the context of TDD) should be part of your DoD. That is a point where I would fully disagree. As a developer, you could always optimize or clean up your code. I would rather than putting refactoring on the list, add the process of code review to the DoD. You ensure with that, that a certain code quality is reached, it is actually measurable and there is room for discussion. 

## End

So I hope I could show you what a DoD means to me and how you could use it. If you are already using it, I would be happy to see your version of DoDs. 

#### Footnotes

> <sup>1</sup> In Scrum context I would define the agile team as the team containing developers, designers (could be also counted as developers), product owner and Scrum master.
The Eternal Self Constraining Pseudo Student
Tags: learning, beginners, experience
Published: 2018-06-14 15:01:53

---
title: The Eternal Self Constraining Pseudo Student
published: true
description: Introspection on what keeps me from acting by procrastinating.
tags: #Learning #Beginner #Experience
---
<img src="https://thepracticaldev.s3.amazonaws.com/i/gmqwgnsjz8ipwzlgbeaa.jpg" alt="Has this good thing turned into a self imposed prison?">

Should I read more? More manuals? More books? Should I watch more? More tutorials? More lessons? Should I listen more? More podcasts? Or should I just dive in and do? Iron out the kinks as I go along? Pick up material as and when it is needed? Am I hiding behind a fear of the unknown, using this “need to learn more” as a scapegoat?

Today, when pushed against the wall, I realized that this, indeed, might just be the case. RawTherapee is the software I am now using to edit photographs. Having gotten so used to Lightroom, this new software is a beast to get to grips with. Everything really is, the first time round. And the lure of the familiar triples that percieved difficulty. The event that forced me to learn about features of RawTherapee that I need for my day to day editing was a godsent. It forced me to look through the software to figure out how to carry out certain editing operations that I have been otherwise lax to learn.

Beyond this, what else I’m I putting off doing because the difficulty of actually learning it is so uncomfortable I would rather spend hours reading/watching/listening to learning media? It is now time to take stock. Time to work on that personal photography project. Time to start building. Time to bring out the drawing/painting material and create. Time to join an open source project and contribute. Time to put away the literature/videos/podcasts (other than for use as reference when stuck) and just do.

Sketch from photograph Libre by <a href="https://unsplash.com/photos/lk5MYKmGyFE?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" target="_blank">Tony Rojas</a> on <a href="https://unsplash.com/search/photos/blindfold?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" target="_blank">Unsplash</a>

<a href="http://rawtherapee.com/" target="_blank">RawTherapee</a>
What's your approach to fixing a "long-term" hairy bug?
Tags: discuss
Published: 2018-06-14 14:52:34

---
title: What's your approach to fixing a "long-term" hairy bug? 
published: true
description: 
tags: discuss
---

You come across an issue that just ain't getting fixed in a short amount of time? What goes through your head, what do you begin to think about?
Which contentious opinions in programming actually matter?
Tags: discuss, webdev, programming, grannyrulescomments
Published: 2018-06-14 13:56:41

---
title: Which contentious opinions in programming actually matter?
published: true
description: Trying to have a positive conversation about stereotypical programming opinions.   
tags: discuss, webdev, programming, grannyRulesComments
---

I think this question would breed a toxic comment section if it was posted in most places on the internet but I think the dev.to community is up to the challenge for a positive chat about stereotypical programming opinions! So hold my beer, here goes... 

There are more stereotypical opinions floating around the development community than you can shake a stick at: tabs vs spaces, Windows vs Mac, nano vs vim etc...
 
The vast majority don't really matter in the long run, however I am interested in peoples opinions about which stereotypically contentious issues actually make a difference and have as close to a generally accepted 'correct answer' as you are likely to find in programming? 

An example (in my current opinion) to mull over: `"the less code you write the better"` I find this breeds unreadable code that causes knowledge silos and junior devs to spontaneously combust when they see it.  

The difference in opinions in the topics raised are potential powder kegs so please try and be respectful if you respond. If in doubt, just imagine you are discussing it with your granny.
Do you use Service Workers in production? How has your experience been like? 
Tags: javascript, serviceworker, webdev
Published: 2018-06-14 13:23:12

---
title: Do you use Service Workers in production? How has your experience been like? 
published: true
description: How are people using Service Workers?
tags: javascript, serviceworker, webdev
---

If you have used Service Workers in  production, I'd like to hear about it!

* How did you realize you needed them?

* How was your experience setting it up, and maintaining it? 

* Results? Demos? 

Thank you all!
How to Choose the Best Static Site Generator in 2020
Tags: javascript, webdev, gatsby, beginners
Published: 2020-01-30 19:31:05

---
title: How to Choose the Best Static Site Generator in 2020
published: true
tags: javascript, webdev, gatsby, beginners
canonical_url: https://snipcart.com/blog/choose-best-static-site-generator
---

![Picking the Best Static Site Generator for Your Next Project](https://snipcart.com/media/204774/best-static-site-generator-2020.png)

So.

Many.

Static site generators.

Even for us who've done 20+ [demos & tutorials](https://snipcart.com/blog/categories/jamstack) with them, it gets overwhelming.

I can't imagine what it must be like for a developer just learning about the JAMstack.

![Like landing in freakin’ wonderland](https://media.giphy.com/media/ACLCA6bvwBEvC/giphy.gif)
<div class="caption">Like landing in freakin’ wonderland</div>

To try and help, we synthesized our knowledge into one comprehensive piece.

By the end of this post, you should be able **to find the best static site generator (SSG) for any project.**

Here's what you'll learn about SSGs:

1. What they are (and why you should use them)
2. What are the best static site generators in 2020
3. Considerations before choosing *the one*

## 1. What are static site generators? 

If you're looking for the right SSG, I assume you have a decent understanding of what they are. Still, a bit of context can't hurt.

Static sites aren't new. They were what we used to build the web before dynamic CMSs (WordPress, Drupal, etc.) took over.

What's new, then? Modern tools—like static site generators—came out over the last years and expanded the capabilities of static sites.

Simply put, a static site generator is an application that takes your site content, applies it to templates, and generates a structure of purely static HTML files ready to be delivered to visitors. The application itself can be written in any language: Ruby (Jekyll), Go (Hugo), JavaScript (Gatsby, 11ty).

→ Read the full post [here](https://snipcart.com/blog/choose-best-static-site-generator)
Best and quickest to learn how to build a full stack web app and Javascript?
Tags: javascript, discuss
Published: 2018-06-14 08:46:53

---
title: Best and quickest to learn how to build a full stack web app and Javascript?
published: true
description: Learning how to program an app and javascript
tags: Javascript, discuss
---

Hi,

I am new to programming. I would love to learn how to quickly and also well learn how to make a web app? What is the best way to learn Javascript? All recommendations welcome but would also love tips and personal advice!