dergachev

# taken from http://www.piware.de/2011/01/creating-an-https-server-in-python/
# generate server.xml with the following command:
#    openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
# run as follows:
#    python simple-https-server.py
# then in your browser, visit:
#    https://localhost:4443

import BaseHTTPServer, SimpleHTTPServer
import ssl

xjamundx

This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.

In that post I talked about 3 main reasons for moving from require.js to webpack:

1. Common JS support
2. NPM support
3. a healthy loader/plugin ecosystem.

Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.

WickyNilliams

So you want to publish a react component?!

This is a quick guide of what you need to do to publish a react component for use by others. This guide is distilled from a conversation [0] on twitter. I will reference individual tweets, where appropriate (thereby shifting blame for incorrect advice from me to the authors :D)

Assumptions

1. You are using some sort of module system in your source
2. You have a build step
3. You want broad support for your component (browser-ready, npm compatible, consumable by bower)

Dr-Nikson

This gist is about token-based authentication (who you are?) with redux

Currently it for clent-side apps only. Not for universall (isomorphic) apps. Will add it soon

0. Requirements

I'm using the promise middleware to dispatch actions like this:

markerikson

// approach 1: define action object in the component
this.props.dispatch({
    type : "EDIT_ITEM_ATTRIBUTES", 
    payload : {
        item : {itemID, itemType},
        newAttributes : newValue,
    }
});

// approach 2: use an action creator function

leonardofed

A curated list of AWS resources to prepare for the AWS Certifications

A curated list of awesome AWS resources you need to prepare for the all 5 AWS Certifications. This gist will include: open source repos, blogs & blogposts, ebooks, PDF, whitepapers, video courses, free lecture, slides, sample test and many other resources.

---

joepie91

While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.

Secure user authentication requires the use of session cookies.

Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.

Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.

*S

addyosmani

Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.

• Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
• One angle to this problem is we all ship too much JavaScript. That's one perspective. We could also look at preprocessing.
• We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
• 1. Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu

clarkbw

const timing = store => next => action => {
  performance.mark(`${action.type}_start`);
  let result = next(action);
  performance.mark(`${action.type}_end`);
  performance.measure(
    `${action.type}`,
    `${action.type}_start`,
    `${action.type}_end`
  );
  return result;

tlrobinson

# Assumes 3 sequential commits:
#
# 1. commit tagged "prettier-before" that added `prettier` depedency and `prettier` script your package.json
# 2. commit that actually ran `prettier` on your entire codebase for the first time
# 3. commit tagged "prettier-after" that fixes any minor issues caused by prettier (e.x. moving eslint-ignore or $FlowFixMe comments around), or just the next commit if there were none
#
# I recommend running these as individual commands, not as a script, in case of merge conflicts
#
# Checkout the non-pretty branch you want to merge
# (or optionally make a new branch with `git checkout -b $YOUR_BRANCH-prettier $YOUR_BRANCH`)