- Probabilistic Data Structures for Web Analytics and Data Mining : A great overview of the space of probabilistic data structures and how they are used in approximation algorithm implementation.
- Models and Issues in Data Stream Systems
- Philippe Flajolet’s contribution to streaming algorithms : A presentation by Jérémie Lumbroso that visits some of the hostorical perspectives and how it all began with Flajolet
- Approximate Frequency Counts over Data Streams by Gurmeet Singh Manku & Rajeev Motwani : One of the early papers on the subject.
- [Methods for Finding Frequent Items in Data Streams](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.187.9800&rep=rep1&t
Any running process has several memory regions: code, read-only data, read-write data, et cetera. Some regions, such as code and read-only data, are static and do not change over time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called heap, and a region called stack. Heap holds dynamic memory allocations, and stack is mostly used for keeping function frames.
Both stack and heap can grow. An OS doesn't know in advance whether stack or heap will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:
- Layout static memory regions at the edges of process's virtual memory
- Put heap and stack on edges too, and let them grow towards each other: one grows up, one grows down
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
Undo/Redo is one of those features of an application that you almost always need to have if you are building serious GUI tools for people to do work.
The best way to look at undo/redo is two stacks of operations the user has performed:
- The Undo stack is the "history" of what they've done
- The redo stack is the breadcrumbs back to the initial state before they started undoing
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
,elem.offsetTop
,elem.offsetWidth
,elem.offsetHeight
,elem.offsetParent
Cheng Lou, a former member of the React team, gave an incredible talk at React Europe 2016 entitled "On the Spectrum of Abstraction". That talk is available for viewing here: https://www.youtube.com/watch?v=mVVNJKv9esE
It's only a half-hour, but it is mind-blowing. It's worth re-watching two or three times, to let the ideas sink in.
I just rewatched the talk for some research, and wrote down a summary that's semi-transcript-ish. I didn't see any other transcripts for this talk, other than the auto-generated closed captions, so I wanted to share for reference.
Ok. I'm going to list off some ideas for projects. You will have to determine if any particular idea is good enough to include in a portfolio. These aren't creative ideas. They likely already exist. Some are way too advanced while others are simplistic.
I will recommend to post any project you make to github and make a github project page for it. Explain in as much detail as possible how you made it, how it can be improved etc. Document it.
If you pick an advanced idea, setup a development roadmap and follow it. This will show some project management skills.
Another piece of advice for those who are design challenged. Use different front end frameworks and use different themes for those frameworks to provide appealing designs without looking like yet another bootstrap site.
// 1 | |
// / \ | |
// 2 3 | |
// / \ | |
// 4 5 | |
// "1 2 3 * * 4 5 * * * *" | |
public String serialize(TreeNode root) { | |
if(root == null) | |
return ""; |
Okay, the title of this post is a bit of a lie. There's no one secret trick to becoming a genius programmer - there are two, and they're more habits than tricks. Nevertheless, these kind of 'secret tricks' seem to resonate with people, so I went for this title anyway.
Every once in a while, a somewhat strange thing happens to me. I'll be helping somebody out on IRC - usually a beginner - answering a number of their questions in rapid succession, about a variety of topics. Then after a while, they call me a "genius" for being able to answer everything they're asking; either directly, or while talking about me to somebody else.
Now, I don't really agree with this "genius" characterization, and it can make me feel a bit awkward, but it shows that a lot of developers have a somewhat idealistic and nebulous notion of the "genius programmer" - the programmer that knows everything, who can do everything, who's never stumped by a problem, and of which ther