| // Get all users | |
| var url = "http://localhost:8080/api/v1/users"; | |
| var xhr = new XMLHttpRequest() | |
| xhr.open('GET', url, true) | |
| xhr.onload = function () { | |
| var users = JSON.parse(xhr.responseText); | |
| if (xhr.readyState == 4 && xhr.status == "200") { | |
| console.table(users); | |
| } else { | |
| console.error(users); |
| FROM ubuntu:trusty | |
| ENV HOME /root | |
| ENV LC_ALL C.UTF-8 | |
| ENV LANG en_US.UTF-8 | |
| ENV LANGUAGE en_US.UTF-8 | |
| RUN add-apt-repository ppa:ondrej/php && \ | |
| apt-get update |
Just migrated it from Codepen.io to markdown. Credit goes to David Conner.
| Working with DOM | Working with JS | Working With Functions |
|---|---|---|
| Accessing Dom Elements | Add/Remove Array Item | Add Default Arguments to Function |
| Grab Children/Parent Node(s) | Add/Remove Object Properties | Throttle/Debounce Functions |
| Create DOM Elements | Conditionals |
Whenever we change our templates we still have to use our build script and this can get annoying. Thankfully with webpack-dev-server and BrowserSync we can fix this:
npm i -D browser-sync browser-sync-webpack-plugin webpack-dev-server
BrowserSync will act like a proxy, waiting for webpack to do its thing and then reloading the browser for us.
Many people struggle with this question. Some just try to make as much as a full-time employee makes (and ignore that they won't be able to bill as many days). Others follow tips on startup related websites that suggest to ask for 20% to 50% more than an salary would yield (and ignore the additional risk and expenses they have).
Below you will find some numbers to help you calculate how high your hourly or daily rate should be.
- You take more risk than full time employees, phases without income are likely
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers:
- SUIT CSS naming conventions + SUIT CSS design principles;
- PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
- Flexbox is awesome. No need for grid framework;
- Normalize.css, base styles and variables are solid foundation for all components;
| —– BEGIN LICENSE —– | |
| eldon | |
| Single User License | |
| EA7E-1122628 | |
| C0360740 20724B8A 30420C09 6D7E046F | |
| 3F5D5FBB 17EF95DA 2BA7BB27 CCB14947 | |
| 27A316BE 8BCF4BC0 252FB8FF FD97DF71 | |
| B11A1DA9 F7119CA0 31984BB9 7D71700C | |
| 2C728BF8 B952E5F5 B941FF64 6D7979DA | |
| B8EB32F8 8D415F8E F16FE657 A35381CC |
