Latest Items
- Latency numbers every programmer should knowContinue reading...
latency.markdown
Latency numbers every programmer should know
L1 cache reference ......................... 0.5 ns Branch mispredict ............................ 5 ns L2 cache reference ........................... 7 ns Mutex lock/unlock ........................... 25 ns Main memory reference ...................... 100 ns Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs SSD random read ........................ 150,000 ns = 150 µs Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs Round trip within same datacenter ...... 500,000 ns = 0.5 ms Read 1 MB sequentially from SSD* ..... 1,000,000 ns = 1 ms Disk seek ........................... 10,000,000 ns = 10 ms Read 1 MB sequentially from disk .... 20,000,000 ns = 20 ms Send packet CA->Netherlands->CA .... 150,000,000 ns = 150 msAssuming ~1GB/sec SSD
Visual chart provided by ayshen
Data by Jeff Dean
Originally by Peter Norvig
latency_humanized.markdown
Lets multiply all these durations by a billion:
Magnitudes:
Minute:
L1 cache reference 0.5 s One heart beat (0.5 s) Branch mispredict 5 s Yawn L2 cache reference 7 s Long yawn Mutex lock/unlock 25 s Making a coffeeHour:
Main memory reference 100 s Brushing your teeth Compress 1K bytes with Zippy 50 min One episode of a TV show (including ad breaks)Day:
Send 2K bytes over 1 Gbps network 5.5 hr From lunch to end of work dayWeek
SSD random read 1.7 days A normal weekend Read... - Rails Model XOR Validation for "Custom" fields
XOR Validation
validate :disease_or_custom_disease #... private def disease_or_custom_disease custom_disease.blank? ^ disease_id.blank? end - From Ember to React — Part 2: Top-Level component concerns
From Ember to React — Part 2: Top-Level component concernsIn Part 1 of “From Ember to React” series I introduced a pattern to re-use data fetched in a Top-Level component into his children. Then I started to realize that I could make use of this pattern to bring even more ideas from Ember into React! Here are a couple I used lately: Loading IndicatorSometimes we want to show a “Loading indicator” to let the users know when a request is being processed. As suggested by this post, logic and markup should be placed on a top-level component to be reused by subsequent components. As before, I remembered a handy Ember feature called Loading / Error Substates already baked into the framework itself. Turns out our previous “High-order Component & Wrapper”-pattern is a perfect place to replicate this pattern, as we don’t need to repeat the loader in every single component: https://medium.com/media/ec2fac98ca4ed538bc899a4295fce611/hrefThis way we can re-use the Loader logic in children components in case we need to hit another remote API: https://medium.com/media/af3f5c7ef9f387213194403a39f00991/hrefError HandlingWe can apply a similar pattern for error handling, in this case I would use...
Continue reading... - From Ember to React — Part 1: Data fetching optimization for react-router nested routes
From Ember to React — Part 1: Data fetching optimization for react-router nested routesWhile refactoring a section of our React app at HealthTree I stumbled upon a common use-case where a parent route/component could potentially share (part of) his data context with his children components, something like: | <Route path> | Component | API call | |--------------|----------------|--------------------| | /tasks | <TaskList ...> | GET /api/tasks | | /tasks/:id | <Task ...> | GET /api/tasks/:id |As a newcomer, the obvious way to handle this in React (& react-router) is to have data fetching logic in both components’ lifecycle methods: https://medium.com/media/8ac23fd22e6903cc659ffa1160fb5bdf/hrefFor some use-cases like this one, data fetched in the first component can be re-used for the second one, thus we have an opportunity to potentially save some bandwidth and improve user experience! After Googling a bit, I found this approach to send state to a route via the Link component: https://medium.com/media/9c11de14c064ee8dbab64d434ea65c4a/hrefThat’s cleaner, as we only load the task once, but having to use this.props.location to pass data looks weird, and also this doesn’t solve the fact that it breaks deep linking inside our app! as navigating to the URL or refreshing it will fail to get the state context. Cross-pollination...
Continue reading... - Import Apple Health
Our main goal with Sundly is to empower people by owning and being in full control of their personal health records. One of the items in our public roadmap was to have a way to import medical records from existing apps, such as as Apple Health. Among other features in our backlog, we asked Twitter for feedback on how to prioritize the development: https://twitter.com/getsundly/status/1079109967762776064We’re please to announce a MVP version of such functionality, check out the following video or the steps ahead: https://medium.com/media/f2f8fc3a0fe814dee397272bf1b7002e/hrefStep by StepOpen Apple Health in iOSProfile > Export Health DataUnzip export_cda.xml fileOpen Sundly > Sign inGo to Settings > Click “Import CDA” buttonSelect file export_cda.xmlImport Apple Health was originally published in Sundly on Medium, where people are continuing the conversation by highlighting and...
Continue reading... - How we hacked a prototype before lunch
We recently had a 3-day Design Sprint at Ecaresoft. The challenge was about tackling the prioritization of incoming bug fixes, feature requests, technical support, etc… (psst… want to learn what a Design Sprint is? check this out: https://designsprintkit.withgoogle.com) Naturally, there are already existing solutions in this particular space, like ZenDesk, Jira, FreshDesk, etc. Without entering into many details, we already use some solutions internally at Ecaresoft. Therefore we didn’t want to simplify the whole design sprint output as simply deciding to use new tools, we could do better. Fast forward to the last part of the design sprint, it consists on throwing out a prototype of the ideas gathered in the prior days. We narrowed the solution components into 3 mini-teams: Design: MockupAlgorithm: PrioritizationTechnology: Proof of ConceptWe took the tech side of things and started to research about existing tools to get the job done. We didn’t want to just use existing solutions and stitch ’em together (with Zapier, for example), but we also didn’t wanted to throw many lines of code for a simple prototype. We considered falling back to Airtable or Coda.io, but the use case was too complex for these tools. Meet RetoolRetool is a new startup tackling the challenge of creating simple “internal” apps with few clicks and even fewer lines of code (or none), a concept know as “visual programming”. Literally its founders want it to be the Visual Basic of Web 2.0! When we show Retool to people, they often think “oh! it’s visual basic for the web!”. And in...
Continue reading... - gist:08162f1182845d3d41a494182044640aVerifying my Blockstack ID is secured with the address 1DAj3qXbJRVG6WTSAJv7DSSN6f5uVwFqBG https://explorer.blockstack.org/address/1DAj3qXbJRVG6WTSAJv7DSSN6f5uVwFqBG
- Hacking a Trello card velocity tracker with Glitch
At Nimbo X we use Trello to keep track of our Kanban development pipeline. We needed a way to track the card velocity/cadence of our development team. Unfortunately most existing products weren’t free and offered much more functionality. The ones free were outdated or mediocre at best.
I remixed a Trello card velocity trackerusing Glitch. I’m very impressed how easy it was, definitely feels like the future for collaborative coding & quick hacking.
Code: https://glitch.com/edit/#!/trello-cards-velocity
App: https://trello-cards-velocity.glitch.me/
https://trello-cards-velocity.glitch.me/ Hacking a Trello card velocity tracker with Glitch was originally published in The Backlog by Ecaresoft on Medium, where people are continuing the conversation by highlighting and responding to this story.
- Creating a serverless web app with Airtable, Glitch, Node.js, Surge.sh & Ember.js
Continue reading...TL;DR;In this post I show how I built a serverless CMS/Blog system based entirely on free and modern PaaS services such as Airtable, Glitch (formerly Gomix, Hyperdev) & Surge.sh.The end result is:https://medium.com/media/c04f0af49229ba610972f9f1c18d4b35/hrefYou can visit it at: http://caring-eggs.surge.sh/And check out the source code:Frontend: https://github.com/benoror/experiment_blog_xt014_dProxy: https://github.com/benoror/proxy_blog_xt014_d & https://glitch.com/#!/project/keen-gorillaOk, tell me more…Lately I’ve been thinking how server code is becoming less and less relevant each day, and how everything you needed to code back in the day is now offered as a cloud service at your disposal, such as:Authentication/authorization (Auth0, Twilio), asset hosting (AWS S3), database (Firebase, Airtable), AI (google prediction API), payment processing (Stripe), etc…The remaining parts of your app, the ones that make you “unique”, can be written in isolated & scalable modules in any language and/or framework of choice, which nowadays can be also easily deployed. Such easy-to-deploy, lego-like blocks of functionality can be achieved with modern services such as AWS Lambda, Zeit Now or, what concerns us today, Glitch.Since I’ve been messing around with these ideas for a while, I decided to see how doable it really was by making a PoC:A Markdown Blog system, à la Canvas or Medium, with Airtable as Database/CMSPaaS ArchitectureDisclaimer: I chose services I’m interested in and/or using at the moment, altough the stack can be flexible at every level:Database/CMShttps://airtable.comAlternatives: Fieldbook (see my related post) , Firebase Realtime, etc…Node.js Proxy/Auth Backendhttps://glitch.comAlternatives: Heroku, Zeit Now, Parse, Aerobatic, AWS Lambda, etc…Ember.js SPA Frontendhttps://surge.shAlternatives: Zeit Now, Aerobatic, Firebase Hosting, Pagefront, AWS S3, Github Pages, etc…Designing the Database StructurePosts tablehttps://airtable.com/shrwpGUmpyeRtvpfTAuthors tablehttps://airtable.com/shradskAUbxUeUPhfComments tablehttps://airtable.com/shriWy0K1HdG8qTs9Crafting a nice client with Ember.jsI won’t enter into much details here, but I prototyped a blog app with Ember.js, using my own ember-airtable data adapter addon. If you like to learn more make sure to check out my post about it.I chose Ember.js since it’s the framework we’re currently using at work (Nimbo X), but you can use whatever framework/library you like, say React, Angular, Vue, etc…The Ember app’s source code is available at: https://github.com/benoror/experiment_blog_xt014_dAt this point Ember Data’s Adapter is pointing directly to the Airtable API URL while exposing the secret API token to the browser, which is clearly not an ideal situation.To overcome this issue I decided to pull a trick up the sleeve…Setting up an HTTP ProxyStoring credentials in a server is a good idea to keep them private. Also interesting are the possibilities of this architecture, as we can provide other kind of functionalities at this layer, such as Auth (albeit our experiment might become less serverless), but that’s material for a future post.First I decided to avoid reinventing the wheel and use http-proxy-middleware to redirect request to my Airtable API. The code snippet to accomplish it is:https://medium.com/media/31890724b2289367316618c0452d2325/hrefDeploying the thingy…Deploying an app into Glitch is a breeze, as you can import the code from a Git repository, or edit it directly in the browser:Storing secretsWith Glitch you can set .env file with the API secrets, visible only to you:Tip: If you decide to use Zeit Now they recently announced support for environment variables and secrets!Now we can change our Ember adapter accordingly:Surge.shAs usual business, deploying to Surge.sh is a piece of cake. We can see the application running immediately afterwards:...
Generated at Mar 28, 2026, 9:32 PM