start new:
tmux
start new with session name:
tmux new -s myname
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 |
#!/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" |
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.
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.
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
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.