aksonov

What is RNRF (react-native-router-flux)?

React Native is great product but lacks for stable, intuitive and easy navigation API during many years. Every year we see new, better API: Native Navigator, ex-Navigator, NavigationExperimental, ex-Navigation, wix native navigation, airbnb native navigation, ReactNavigation...

Once I've started React Native development, in 2015, I created RNRF - simple API for easy navigation. It was clear that better navigation instruments will come later but I didn't want to change my code again and again to switch for better API. Every new major version of RNRF is based on different navigation framework and mostly preserves own API.

Another goal was to represent all navigation flow within one place in clear, human-readable way - similar to iOS Storyboards concept. This way other engineers could understand your app flow faster.

heron2014

Visual instructions how to enable Google Maps on IOS using react-native-maps

UPDATE: Following instructions are now a year old. I have recently managed to upgrade react-native-maps from 0.17 to the latest version 0.21 with react-native 0.51 - if you want to follow my instruction scroll down to the end this doc! Hope that will work for you too!

This is for my personal use, things might not be correctly explained here. For the official docs please check https://github.com/airbnb/react-native-maps

Steps from scratch:

1.react-native init GoogleMapPlayground

Sewdn

TL;DR

Meteor is great at sharing code between different builds for different platforms. You can use the same source for your browser builds, server builds, your builds for iOS, Android, ... But how to organize your project to be able to orchestrate your builds for different apps and services from the same source? This post elaborates on the reasons why you need these different builds and how you could accomplish this with Meteor easily.

Use cases: Why would you build different apps?

1. Different apps for different roles

Say you have an app with completely different end user experiences depending on their role. It is common practice to have the user logged in, check her authorization (role) and then setup different routes or load different templates to serve that type of user’s needs. While doing so, all types of users load the same build and the app decides what portions of the build to use and what not to use.

mcollina

#!/bin/bash

sysctl net.core.rmem_default=268435456
sysctl net.core.wmem_default=268435456
sysctl net.core.rmem_max=268435456
sysctl net.core.wmem_max=268435456
sysctl net.core.netdev_max_backlog=100000
sysctl "net.ipv4.tcp_rmem=4096 16384 134217728"
sysctl "net.ipv4.tcp_wmem=4096 16384 134217728"
sysctl "net.ipv4.tcp_mem=786432 1048576 268435456"

MohamedAlaa

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

jboner

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD