Really sorry ... this is a very old post, and I don't have the images with me any longer. I think they may have been lost in one of the platform upgrades. Syed Fazle Rahman , any clue? Bráulio Bhavamitra , in the meanwhile, you could use the Codepens mentioned in the article. they have the actual running example.

One of the languages that bring out the most angst in me is SQL. When writing a query, I usually think: Use this table (FROM T1) Choose a column which has more details in another table, T2 (USING column) Join with that table (T2) Make a decision on what to do with the join where T2 doesn't have a value that's there in this table, typically, include the row, but use NULL values from T2 (LEFT OUTER JOIN T2) Keep only rows that match a certain condition (WHERE condition) Fetch me columns A, B, C from this result (SELECT columns) But when writing that in SQL, I have to start at 6, got to 1, then 4, then 3, then 2 and finally 5. See what I mean?

Ask me to choose the best Android Phone for them Want me to fix their television's WiFi And this takes the cake ... "I want to talk to you about using blockchain for my business"

Oh, I had multiple choices of career. Electrical Engineer (which I was for 3 years), Computer Hardware engineer, Financial Analyst/Banker and Production Engineer. But I knew software was my calling, so I worked hard to find a software job. This was way back in the early 90s, when there weren't that many software jobs (1/100th of today is my guess). So I had trouble finding a one, especially since I had to switch from EE. If I hadn't landed a software job then, I would have been one of the others. Today, I'd choose be a Product Manager (for software products, of course) if not a developer.

I think what you are looking for are the offset() and skip() functions available on the result of find() either directly using the MongoDB driver or via Mongoose. I believe the plugin you are using should also have support for these functions. You should also be aware of caveats when using these when the total number of pages could be large. In fact I have devoted a full section to discuss pagination in my book Pro MERN Stack, the code for which you can find in this github repo . You could directly use that code if you are using React and Bootstrap, but could use the concepts otherwise.

In addition to most of the above, I've faced these as well: Are you sure you deployed the version with my latest code? (This was in a CI environment!) Must be a bug in the library (eg, jQuery). I found a bug in the compiler. (Really, I'm not kidding! But this was in the days when the Microsoft C++ compiler did have a few bugs).

#2 - PermGen size - not just the initial load, but multiple reloads of the same code can also cause JVM to run out of PermGen space. For some reason, the JVM doesn't reuse PermGen when it reloads code. I've often encountered running out of PermGen space in Tomcat. In a dev env, I usually have the auto-reload on changes set to ON. As I change code and compile multiple times, the JVM+Tomcat reloads my code. After about a day's work, I hit the PermGen out of memory error. When I hit this error, I have to restart Tomcat. But on production, I've never hit this error, since auto re-loading is switched off. We usually restart tomcat whenever new code is deployed. #3 - You need to be careful while reducing Xss value. If your call stack is deep, you may hit a Stack Overflow error if Xss is too small. 512k (the default) seems quite OK to me. Even with 100 threads, it will take only 50 Mb. If a project has more threads than this, well, I'd take a real hard look at why you have so many threads on a single machine. If it's a powerful machine, say with 64 cores which can really handle that many threads due to simultaneous user requests, I'd expect it to have lots more memory as well, like 64G or 128G. Then, even with 1000 threads, the stack memory is still just half-a-gig, a very small percentage of the total server memory.

The best estimates I have been able to give are by splitting the work into as many smaller tasks as possible. They should be small enough that you are very confident of the estimated time. A day's work is good for many people (ie, if any task is more than a day's work, split it). For some others, it's half-a-day. If you do have really very uncertain things, give an estimate for how you can get more clarity, and then do the real estimate only once you get reasonable clarity. Alternatively, make an initial estimate (but make it explicit that it is rough), and re-estimate when you have more clarity. It's important to get the uncertain things out of the way first before doing real work.

Before get to server-less, can we first define what is a "server"? Once upon a time, we had a machine in the office, and we opened a port in the firewall, forwarded it, managed its IP address, and let people access it's /var/www/html from the internet. A real server that we could touch and feel. Then, some Data Center folks came by and said you don't need to deal with the power, internet and cooling for this machine, we'll keep it in our racks. So we moved the machine to the Data Center. We no longer had to manage the infrastructure. But it was our server, we still owned it. Then the Cloud happened. We installed the same Ubuntu 10.04 on a "virtual" machine on AWS and ran our application on it. Now, we didn't have to worry about IBM vs. HP servers, or the efficiency of an FSB and the merits of RAID-5 vs. RAID-1. When people asked me where's your server, I said AWS. Yes, a server, just someone else's, we rented a portion of it. Soon, Google AppEngine and Heroku appeared on the scene. They called themselves PaaS . We still had to write all the code and deploy it, but we didn't have to worry about whether it was Ubuntu 10.04 or 11.10, ext3 or ext4, ssh keys, and LC_LANG errors. Slightly better than a cloud server, but I'd say, still a server. We were now renting a portion and a time-slice of it. Now, we have Lambda and Google Functions. Great, I thought at first, but it is just old wine in a new bottle. They are containers like AppEngine and Heroku, but at a much granular time-slice of billing. Seconds instead of hours. In return for this gain, we're penalized with a high spin up time (or latency) for every request and lack of local storage. Is this a server? Oh, yes, That's why we've to specify the amount of RAM, the amount of CPU etc. that's allocated for the function's execution. Note that you cannot run a real web-server that supports a user interface (because of the spin-up latency). It's good only for background or batch jobs. Also, the fact that you are billed even when waiting for downstream servers (eg, an S3 request or a database call) to respond seems a waste. Within the Lambda, if we make an API call, and it takes 5 seconds, you're billed for those 5 seconds just for waiting! Here's my vision of truly server-less computing: (a) Imagine a farm of Node.js servers already up and running. It has all the common npm modules already available -- like express, body-parser and google-apis, aws-sdk and mongoose. All your code snippet has to do is define is a route handler, which is just a few KB at max. And you can have lots of such code snippets. When a request hits one of the Node.js servers in the farm with your matching route, it downloads the appropriate code snippet from a nearby cache (no spin up time, mind you) and runs it. While any async calls to downstream APIs or databases are waiting, we're charged a small amount for saving the context (closure) of the function but not the CPU time. (b) Another thought: really no servers, just API calls. All the code runs on the browser. For persistence, the code uses Google Drive, S3 or Firebase to save data using their APIs. For other services, it uses other APIs, mostly third-party. We're billed only for the API calls, and the code is hosted on a static web-server such as S3 or Google Cloud Storage. In either case, you are not specifying how much RAM you need etc. That to me, is truly serverless (although there is a server there, we're not forced to think about it.)

Thanks, Sid, you've got a very valid point. Paraphrasing: Atomicity means "all or nothing". For example, if after the resource is booked, the user can't be billed, we need to cancel the booking. Better still, the booking should't succeed if billing failed. Atomicity is a bigger deal (as opposed to concurrency) when dealing with MongoDB, as compared to ACID databases. In ACID databases, you can combine the booking and billing in one transaction and make the whole thing fail if any of them fail. When the multiple things that need to be done for consistency are within your database (multiple collections), an ACID database with transaction ability works great. But In real life, things like payment are done asynchronously (by payment gateways) and you can't do it in a transaction (or lock the entire db in MongoDB while waiting for the gateway to send you the result). You need to create rollback or cleanup mechanisms in your own code.