- nylas/N1 💌 An extensible desktop mail app built on the modern web.
- black-screen/black-screen A terminal emulator for the 21st century.
- shockone/black-screen A terminal emulator for the 21st century.
- ptmt/react-native-macos React Native for macOS
- docker/kitematic Visual Docker Container Management on Mac & Windows
- kitematic/kitematic Visual Docker Container Management on Mac & Windows
- davezuko/wirk-starter Get started with React, Redux, and React-Router!
- TelescopeJS/Telescope 🔭 An open-source social news app built with Meteor & React
- coryhouse/react-slingshot React + Redux starter kit / boile
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;
# .bash_profile | |
# Copy this file on the desired machine. | |
# This script will change your iterm tab color and the background for that tab. | |
# Requirements | |
# - iterm as terminal | |
# - a profile named Prod in iterm. You can configure it how ever you want. A profile can be found in Preferences -> Profiles | |
'use strict'; | |
module.exports = function CustomError(message, extra) { | |
Error.captureStackTrace(this, this.constructor); | |
this.name = this.constructor.name; | |
this.message = message; | |
this.extra = extra; | |
}; | |
require('util').inherits(module.exports, Error); |
#!/bin/bash | |
##################################################### | |
# Name: Bash CheatSheet for Mac OSX | |
# | |
# A little overlook of the Bash basics | |
# | |
# Usage: | |
# | |
# Author: J. Le Coupanec | |
# Date: 2014/11/04 |
/** | |
* example C code using libcurl and json-c | |
* to post and return a payload using | |
* http://jsonplaceholder.typicode.com | |
* | |
* License: | |
* | |
* This code is licensed under MIT license | |
* https://opensource.org/licenses/MIT | |
* |
# | |
# termcolor.pl : http://h2plus.biz/hiromitsu/entry/674 | |
# | |
# Usage: | |
# > coffee termcolor.coffee | |
# | |
sys = require "sys" | |
fg = "\x1b[38;5;" | |
bg = "\x1b[48;5;" | |
rs = "\x1b[0m" |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
-
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the
secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection. -
Use production SSL certificates locally. This is annoying