Data structures and algorithms interview questions and their solutions - <AUTHOR> https://techiedelight.quora.com/500-Data-structures-and-algorithms-interview-questions-and-their-solutions <comment><USER2> When I had less than 5yrs experience I used to ask these types of questions, thinking they showed the ability of a developer to reason out critical software issues. Then I met a guy who had practically memorized everything I could ask. He spit out answers so fast it was appallingly clear he was regurgitating answers from a book. This proved nothing about him and everything about me.

Today, I recognize that good software development owes nothing to data structure knowledge or obscure algorithms. This knowledge can't hurt but very few jobs or languages require you build a skip list from scratch. Instead, writing good software requires the ability to maintain a system, to debug problems, and to give constructive code review. That's it.

<comment><USER3> >Today, I recognize that good software development owes nothing to data structure knowledge or obscure algorithms. This knowledge can't hurt but very few jobs or languages require you build a skip list from scratch. Instead, writing good software requires the ability to maintain a system, to debug problems, and to give constructive code review. That's it.

While I don't think that the current state of interviewing is perfect, this statement is pretty out there. Good software development owes NOTHING to data structure knowledge? Choosing the right data structure is critical for software that performs well (or performs at all once you get to a certain scale), and demonstrating knowledge of various data structures shows at least that a candidate knows a bit about which tools they have available to them on the job.

Of course not many people are implementing skip lists from scratch in their everyday job, that's why in the list of 500 questions none of them are "Implement a skip list". Data structure questions rarely ask you to implement some data structure from scratch, they ask you to look at a problem and figure out which data structure best lends itself to the solution.

I won't argue that asking questions about obscure algorithms isn't a problem, but good interviewers aren't asking questions that need obscure algorithms, they are asking questions that need algorithms like DFS, basic variations of sorting, and basic DP problems.

<comment><USER4> You're focusing too much on a particular phrase and not enough on the overall meaning. Read this again:

> Instead, writing good software requires the ability to maintain a system, to > debug problems, and to give constructive code review. That's it.

Code review is the best time to talk about data structures and algorithms as they are a time to apply theoretical knowledge to real world problems. Good, constructive code reviews are about education and maintaining a quality code base.

Interview questions about data structures and algorithms rewards memorization and classroom knowledge. I've worked with way too many mediocre developers who are great at whiteboarding interview questions but who couldn't build a maintainable system if their lives depended on it. Consequently, I don't give a damn about a candidate's performance on these types of questions. Instead, I'd rather learn about some projects they've built, problems they've experienced and their experience with code reviews.

</comment></comment></comment><comment><USER5> \- Programmers are increasingly more "API plumbers", not "pathfinders". The change being you have to more often create an "easy to maintain" glue layer between lots of existing code (most of which your company wrote a bunch of years ago, or is external to your code in a framework or library) instead of solving a problem from scratch using CS basics. Interview questions haven't shifted to "this library has such and such function calls, how would you expect it to report an error?" or "describe two distinct UI frameworks you have used and explain their differences". They're still very much in the era of OK we have two rectangles, how do we find the overlapping pixels.

\- Software is increasingly built in teams. We don't ask about "how you handled a difficult person on your code review" or "how would you break this change in to two logical commits" or even "what's a good name for this function", all of which are more important than knowing the big-o for some obscure interval tree.

\- CS 101 algorithms have very little to do with how they are implemented. e.g, in a recent discussion with a co-worker I discovered libstdc++ hashtable's iteration orders depend not only on hash code but also on insertion order. Looking at how libstdc++ and MSVC implemented hashtables was both very difficult and exhausting to follow and had many many more details than the typical CS 101 approach of just hash the key and direct lookup the bucket! Turns out writing code that is really fast needs more than knowing the big-o.

\- Big O is such a garbage simplification of all the "fundamental" knowledge. Why not just ask some fundamental graph or combinatoric counting questions? Why nothing about what is computable and what is not, or which languages are regular? What about information theory? How come no information recall or database questions? or even these days with all the ML, why not some basic linear algebra?

</comment><comment><USER6> Here's my gripe with this interview process. It encourages engineers to spend months and years into learning and remembering optimal solutions to textbook problems.

A REAL engineer would spend the same time doing something productive....things like:

\- Writing a sql optimization for their current company that saves resources

\- Creating shared memory interfaces for faster processing of logs

\- Modifying filesystems or kernel to create their own log processing

\- Modifying JVM to optimize critical code

\- Rewriting parts of a server to set up security alerts

\- Fast encryption and decryption of in-memory cache records

\- Writing an interpreter for faster generation of low level code for high speed processing

\- And on and on

My point is, today's interview process treats engineers with such complicated experience as shit because they spent time working on complex projects and couldn't memorize these questions. But then these same companies will hire some mediocre engineer who cannot think out of the box but is an expert at memorization.

Said mediocre engineers then hire other mediocre engineers using the same process, because these mediocre engineers do not even have the ability to grasp what kind of engineering would lead to above points.

To top it off, these same mediocre engineers sweep this problem under the rug claiming they are trying to reduce false negatives. Lol!

Sad state of the industry!

<comment><USER7> If this materially impacts the bottom lines of companies that are practicing this approach eventually companies that are not using this process will prevail.

<comment><USER6> >> If this materially impacts the bottom lines of companies that are practicing this approach eventually companies that are not using this process will prevail.

It would, if companies realize that they can save millions by improving their interview processes and not have to aqui-hire so much.

But this insight requires smart people (who they eliminated with this interview process) to be already hired in those companies.

<comment><USER7> While I highly dislike this trend it's hard for me to call say Sundar Pichai not smart for example.

<comment><USER6> What do you think about Marissa Mayer? For every outlier winner person you point out, the industry is littered with losers. Perhaps stop correlating wrong things together?

<comment><USER7> Well if you theory holds how did Rob Pike, Ken Thompson, Guido van Rossum, Dan Bornstein and on and on ended up at Google?

<comment><USER6> >> Well if you theory holds how did Rob Pike, Ken Thompson, Guido van Rossum, Dan Bornstein and on and on ended up at Google?

You realize they got hired because of their fame and expertise? They didn't have to go through intense whiteboarding. And even if they did, they would be hired even if they didn't solve a stupid N-Queens problem?

<comment><USER7> I realise they have 0 problems with CS fundamentals while being at the same time top experts in respective fields.

<comment><USER6> >> I realise they have 0 problems with CS fundamentals while being at the same time top experts in respective fields.

I suspect your definition of CS fundamentals is only Algos and Datastruct problems. Said experts are very good at what they do. That does not mean they will whip out an algorithmic puzzle solution on a whiteboard under pressure.

I also suspect that those experts have better things to do than get a job at Google. They'd rather not go through this process. Google wants them to be there not the other way around.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> It's a tragedy of our industry that this super FUN list of basic algo problems, is connected in everyone's mind to lame-ass whiteboard interviews. These problems should be like playing scales: engineers should just work through these, practice them till they're no-brainers. But not to land that sweet entry-level SWE job at Google, but just to grease your own wheels in day-to-day coding and problem-solving.

<comment><USER9> I've never been to an interview that would ask this kind of crap, and would be very surprised if a future interview did. So yeah, I'm just looking at it as a list of possibly interesting problems, which makes it a way better link than "interview help".

</comment></comment><comment><USER10> As a fun warm up-question, I always ask the candidate what editor and keyboard they use. The candidate who geeks out about their plugins and cherry switches inevitably passes all 5 rounds; the candidate who uses eclipse with maybe a vim plugin will go on to fail about 75% of the time. It's a good filter too; I'd say 1 out of every 20 candidates expresses strong convictions.

I'm seriously considering using it as a dog whistle and skipping the experience deep-dive (which tests if you are a good story teller), the systems design questions (which tests if you can sync to the interviewer's sense of judgement), and the algorithm hazing (which tests social anxiety). But I'm worried there is some kind of discriminatory correlation baked into that metric.

<comment><USER11> nano and a $10 Logitech k120. What's your verdict?

<comment><USER12> I'm probably just reading this into your comment, but the challenging tone makes it seem like you think OP is pretty misguided... like there's no information to be had here.

But isn't an interest in tools pretty common in most crafts/trades? If I were hiring a woodworker for my cabinet shop, I'd probably ask about favourite tools. I wouldn't actually care if they talked about how a bandsaw beats a tablesaw every time, or launched into a sermon about shopmade wooden handplanes versus metal monstrosities. It's the presence of an opinion at all that matters.

edit: I don't actually have a cabinet shop. :(

<comment><USER13> Tools, yes. But seeing editors and keyboards as the tools indicates that someone is operating at a pretty low level of abstraction. If you asked a civil engineer what their favourite tool for designing bridges over deep valleys was, and they said "a Rotring isograph" [1] rather than "parabolic arches", would you be impressed?

[1] [http://www.cultpens.com/i/q/RT04273/rotring-isograph- technic...](http://www.cultpens.com/i/q/RT04273/rotring-isograph-technical- drawing-pen)

</comment></comment></comment></comment><comment><USER14> I have a friend who memorized all of these types of questions and answers. It worked because he got offers from Google, Facebook and Uber, amongst others. The key is to pretend like you're figuring it out on the spot and not just regurgitating it from memory. I plan on doing the exact same thing when I look for my next job. It's unfortunate, but the reality of the state of our interviews.

</comment><comment><USER8> I have two kinds of questions: (1) tell me about a problem you've solved, and (2) let me tell you about a problem I'm facing. I'll never ask candidates about made up problems. Why would I waste our time talking about fake stuff, when there's so many actual real problems in front of us that we could dive deep on?

<comment><USER15> The best, most fair interviews I've been through follow this pattern. I remember one of them told me about a current problem they had, and told me "You can google anything you want, you have 30 minutes. After that, you should tell me how would you solve this problem, including any tradeoffs you've made".

This is by far the most realistic scenario employees of most companies face. It doesn't matter so much that one doesn't remember the specific details of tree traversal or how linked lists are implemented. It matters much more that one is able to find it out quickly, understand it and apply it. Those are the skills you're looking for.

</comment></comment><comment><USER16> In my opinion, it is great having people trying to "memorize" those questions. If they understand them, it would be like one half of formal computer science studies. What is a shame is people graduated from Computer Science university courses not remembering a clue about algorithms, because they "memorized" just to pass the exam. BTW, some of the interviews may be are too much hard, requiring being a Donald Knuth, having a "intelligence" index of 160, and being a nice team player (if you target very smart people you'll deal with crazy jerks most of the time -until those jerks become tamed, somehow-). Super-smart people should target working for the NASA or similar, not for writing APIs in Python 50 hours a week with just 3 week per year holidays.

Anyway, algorithms matter.

</comment><comment><USER17> Nice list, but a side-note: all this focus on interview-preparation may give the false impression that algorithms and data structures is a closed body of work, when in fact it is an active and lively field of research with many basic questions not yet understood.

Someone could go through these 500 questions and for (almost) all of them formulate variants/extensions that would be open research questions. Or alternatively, ask for each of them: is this the best possible solution? Can I prove it? What if I restrict what the algorithm can do? What if the data comes online? What if the input is noisy? etc. etc. etc.

</comment><comment><USER18> Dear HN,

Please stop telling companies not to use this method of interview.

Sincerely, Michael.

I use it to filter myself out before wasting anyone's time.

What I see here is an AND gate, and their use of this process itself triggers the false in my own filters-for-job-positions system.

I see it as an uniform filter. The company is filtering me out, or in. And, if I understand the reality of their options for filtering methods, I can use that information to filter them back. Interestingly enough, this one is pretty uniform for me, if they use the method of out-of-a-book problems in either an on-the-whiteboard or pair-programming session, they have solved the problem of whether I want to work in that position without my having to trouble myself with memorizing problems to answer, nor waste their time screening me.

The filter I am applying here is against the out-of-the-book part of this. If a company wanted to provide a previously solved bug in a section of their own code, with enough information to debug but perhaps not enough testing written into the system, to me this would not filter that position out. As long as the job would be similar in setup to the methods used during the interview this would be fine by me. Difficult, as the level of chaos internally to any interviewee is very high, and most positions would not be nearly as chaotic as the induced level this hiring process creates.

I think asking on-the-board questions, or running some pair programming, is a filter for perspective, and attempts to identify how an applicant handles chaos.

To put it another way, the company wants people who when they hear an alarm will file out of the business in an orderly fashion, doing that job that has out-of-a-book interviews during hiring. I personally walk towards alarms, not away, and am plenty happy not to be stuck in a position that isn't supposed to have someone like me in it.

My system is tragically flawed, of course. A company could easily use an interview process they consider arbitrary to filter the lowest tier of applicants (non-tech people fishing for a few months paid internet browsing), and I could, not recognizing the insignificance of it, preselect them false when they would have stopped that interview after ten minutes and hired me on a handshake.

</comment><comment><USER19> I would love to see a "this can be solved in O(n)" annotation on each, separate from the solution itself.

</comment><comment><USER20> If you are just asking Algo and probably pseudo code, these questions might help, but if you ask to write the proper code with boundary conditions etc, that makes it difficult even if you know the Algo. Of course I am assuming that no one memorizes the code ;).

<comment><USER19> I used to give people a description of how an algorithm was implemented, and ask them to write it out in code. Specifically we'd take the conversation to boundary conditions, failure conditions, testing, etc, from there. I was reasonably happy with the outcome.

</comment></comment><comment><USER21> The solutions here make the common mistake of ignoring the cost of stack space, and thereby incorrectly claiming that recursive solutions have lower space complexity than iterative solutions.

<comment><USER22> Not if you point out that whatever platform you're coding in employs tail recursion I guess? But yeah the intermediate results will still have to be stored somewhere.

</comment></comment><comment><USER23> here is an article by google vp about their approach to hiring: [https://www.wired.com/2015/04/hire-like- google/](https://www.wired.com/2015/04/hire-like-google/)</comment>


The Disgraceful Lowlands of Writing: On Kafka - <AUTHOR> http://www.openlettersmonthly.com/the-disgraceful-lowlands-of-writing/ <comment><USER2> A good read, thanks.

</comment><comment><USER3> Am I the only one who expected an opinionated article about kafka (the streaming library) and its problems regarding write performance/durability?

I am not saying the library has this problems, just that the title of this article is perfect for that kind of article.

<comment><USER4> Yes, you're the only one. When an article is about Kafka, it's about Kafka. When it's about the streaming library, it's going to be about Kafka the streaming library, and no need to pollute the comment thread with glib remarks about Kafka the streaming library when the article is about Kafka.

<comment><USER5> Aw, that's a bit harsh. It's true that all the Kafkas are welcome here in their own right.</comment></comment></comment>


LzLabs launches product to move mainframe COBOL code to Linux cloud - <AUTHOR> https://techcrunch.com/2016/07/05/lzlabs-launches-product-to-move-mainframe-cobol-code-to-linux-cloud/ <comment><USER2> This is a great space to be in. Contrary to even the tone of the article, mainframes are still widely in use across a huge number of industries. Typically in industries slow to adopt major changes - but we're at a moment where the COBOL skill shortage combined with increasing hardware costs is starting to make these machines untenable for even the largest institutions with the most inertia.

</comment><comment><USER3> Having watched the video this seems like something one could achieve with GNUCobol, mainframe modules ported to the hardware of your choice and using some frosting made of nodejs/<insert hype web tech>. Why don't I feel enthusiastic?</comment>


The Case for the Empire (2002) - <AUTHOR> https://www.weeklystandard.com/jonathan-v-last/the-case-for-the-empire <comment><USER2> In my experience evil is a fruit grown from one of two seeds of desire: either it comes from an individual or group need to impose order, or more precisely their vision of order; or it comes from a need for catharsis by watching the world burn as some part of it descends into anarchy. Both seeds can grow into fruits of atrocious acts of evil.

At the same time, no one individual or group is all bad. You can pick any person or organization and find something good to say about them. I think that is often a good exercise, as long as we don't publicize our thoughts on that (taken out of context they could be interpreted as support of an evil groups broader actions). That Mussolini made the trains run on time is sometimes given as an example. It doesn't change who Mussolini was, or the horrors perpetrated under his command.

Individuals within an evil empire can also have better moral character relative to the others in the empire. Rommel is a case in point. That doesn't change that they participated in the commission of atrocities. It's worth noting that Rommel tried to stop Hitler, Operation Valkyrie.

[https://en.wikipedia.org/wiki/Operation_Valkyrie](https://en.wikipedia.org/wiki/Operation_Valkyrie)</comment>


Indicators that a startup idea is a good one  - <AUTHOR> http://www.theequitykicker.com/2012/11/23/indicators-that-a-startup-idea-is-a-good-one/ <comment><USER2> It's amazing how many reposes pg's post generated.</comment>


The sad long story of Fisker Automotive - <AUTHOR> http://venturebeat.com/2013/04/17/the-sad-long-story-of-fisker-automotive-the-most-tragic-vc-backed-debacle-in-recent-history/

<comment><AUTHOR> It is shocking how much they burned through. $900,000 per vehicle sold (at a $70,000 invoice price)!

Thing is, if the government thought like a VC and figured its loans to Solyndra, Fisker and Tesla as strategic investments in an alternative energy future, then would 1 for 3 look as bad? I don't know that it does or doesn't, but certainly the arguments against bailing out Fisker and Solyndra and blowing a lot of tax payer money are the same as for not bailing out Tesla, which I think (and I may prove to be wrong over time) is looking like it could become a significant win for US industry in the long run, and probably well worth bailing out.

When you consider the sheer volume of dollars spent on Detroit's auto industry and the fossil fuel industry these numbers look much better in perspective.</comment>


Large number of Twitter accounts critical of China suspended - <AUTHOR> https://twitter.com/YaxueCao/status/1134607732718407680 <comment><USER2> Twitter Takes Down Accounts of China Dissidents Ahead of Tiananmen Anniversary

[https://www.nytimes.com/2019/06/01/business/twitter-china- ti...](https://www.nytimes.com/2019/06/01/business/twitter-china- tiananmen.html)

""" In a statement, Twitter said that as a part of its routine efforts to stop spam and inauthentic behavior, it had inadvertently gone after a number of legitimate Chinese-language accounts.

"These accounts were not mass reported by the Chinese authorities — this was routine action on our part," the company said in a statement on Twitter. "Sometimes our routine actions catch false positives or we make errors. We apologize."

Online, many users said they did not believe Twitter's statement told the whole story. """

</comment><comment><USER3> on a similar note the documentary "The Gate of Heavenly Peace," far the best history of the 1989 Tiananmen protests and mass carnage, is available in two parts on YouTube [https://youtu.be/1Gtt2JxmQtg](https://youtu.be/1Gtt2JxmQtg)

people need to be reminded that China hasn't changed in the way they treat anyone critical of this regime. and there are far to many China apologists sitting in power in Silicon Valley (at YC Sam Altman is a prominent case)

</comment><comment><USER4> How does something large scale like this happen? Is it possible to get an account suspended solely by mass reporting of Tweets, or does it require some level of internal access to Twitter?

The former would just mean Twitter needs to tweak their suspension procedures a bit. The latter would be quite worrisome due to the various implications (security breach, internal oversight and approval, rogue employee, etc.).

<comment><USER5> Most of the accounts were probably registered normally with en email address and a handle, only until Twitter presented the accounts with a 'Please verify the account with a phone number', and then they got flagged and banned.

There used to be a loophole in Twitter where you could register accounts _en masse_ (without phone verification), but they have since clamped down on this and now you have to go through rigorous verification steps to prove you're not some bot or trying to run a propaganda campaign.

<comment><USER6> But if one is some running bots for a propaganda campaign that's friendly to Twitter investors' interests, one magically doesn't run into those sorts of verification hoops.

</comment></comment></comment><comment><USER7> They've also restricted my account for no apparent reason a few days ago, and because the account is associated to an older phone number I have no choice but to wait for the mercy of Twitter Support. Makes my lazy ass ponder about the importance of federated solutions such as Mastodon.

<comment><USER8> You can't reuse a verification number across usernames; one of my accounts is locked and wants a phone, but the one I put in is "already in use on another account".

sigh.

</comment></comment><comment><USER9> As long as we keep (as a whole) letting a country that ground dissidents to a paste and washed the result down the sewers, drive our collective greed, we're fucked.

Note I'd prefer not to use the term greed above, it's just the most succinct for the situation but it is the reality.

Minus the invasion, we are pre ww2, concentration camps are happening and we are doing business with those practioners.

I and everyone I have an influence on, are refusing to buy Chinese goods, that's the limit of my power (which is fuck all honestly).

<comment><USER10> > I and everyone I have an influence on, are refusing to buy Chinese goods, > that's the limit of my power (which is fuck all honestly).

What device did you type this message on? Odds are very high it was assembled in China with a significant portion, if not majority, of Chinese-made components, and the company that sold it to you either has a significant presence in the Chinese market, or wishes it did.

I understand the concern here, but for better or worse, China is where pretty much anything that uses transistors is made, and it's just not practical to boycott _everything_ that passes through there.

(Not to mention that it's not really fair to punish Chinese business-owners for the actions of their government when they have even less accountability over it than we do over ours. Is it fair for people of other countries to not buy from American companies because of our government's absurd incarceration rates?)

<comment><USER11> [https://thenib.com/mister-gotcha](https://thenib.com/mister-gotcha)

</comment></comment></comment><comment><USER12> This is exactly why we must support decentralized and censorship-resistant alternatives. Mastodon and Pleroma are steps in the right direction.</comment>


Walmart gives federal government a taste of its own medicine - <AUTHOR> http://townhall.com/columnists/paulgreenberg/2010/07/19/wal-mart_strikes_back

<comment><USER2> That "story", if fit to call it that, completely breaks down by the second page into a ridiculously one-sided, poorly written, and rather immature take on the case at hand.

And frankly, I'm a bit concerned by this idea that a private organization has the resources to drown a regulatory body in red tape without flinching. As citizens who are subject to obscene amounts of neglect by private industry day in and day out, we should be more concerned by the power the private sector seems to be increasingly wielding.

</comment><comment><USER3> I'm really glad that someone has the courage and determination to take the feds on at their own game.

<comment><USER4> Oh _snap_ that's great. I'm buying something at Walmart at the next opportunity.

</comment></comment><comment><USER5> Walmart has started taxing and waterboarding federal officials and invaded D.C. with soldiers and drones? Somehow I doubt it.

</comment><comment><USER6> This news is nearly a year old.

<comment><USER7> Old and poorly written but interesting all the same. I never saw this the first time around and it's a great story that makes me like Walmart even more so I'm grateful for the repost.</comment></comment>


Brad Feld ditches his iPhone - <AUTHOR> http://www.feld.com/wp/archives/2010/05/open-android-vs-closed-iphone.html

<comment><USER2> He lists his reasons in the following order:

 _AT &T service_

Yes, AT&T service has been pretty shitty. It's hard to make this a direct knock against the iPhone, even recognizing the exclusive deal. I believe that Apple is pushing AT&T to fix this issue in one way or another. Though it has been taking way too long. Still, I don't consider this a pure iPhone issue.

 _major limitations in some of the applications such as email_

Really? Have you truly tried some of the Android apps, Brad? The default email client on the Moto Droid I had for a month didn't even support signatures. Many of the other apps I downloaded and tried were half-baked at best. Some were targeted towards specific handsets, others just didn't perform as advertised. There have been very very few iPhone apps that I've downloaded that didn't do what they advertised (note: I also read app reviews first. If the majority of the reviews are 1 or 2 stars I skip it.). My personal experience was that Android apps were fairly poor as a whole, though there were some really good apps too.

 _restriction of Flash_

Until I see true working version of mobile Flash, I don't blame Apple for not including it. I've never felt slighted by my iPhone not supporting Flash.

 _lack of tethering_

This is, again, a carrier issue. So, you're not really comparing handsets, you're comparing carrier restrictions. Again, I get the exclusivity part, but this isn't really an iPhone limitation.

 _lack of statefulness, lack of multi-processing_

Yeah, these bug me at times also. Though not significantly, and my Droid ATE the battery if I tried to multitask an app that did a lot of background network activity. So again, I'm not sure this is true iPhone issue as much as an overall technology issue.

 _and the unbearable shittiness of iTunes for Windows_

What about the unbearable shittiness of Windows in general?

Sorry, but I put less merit into someone who switches products after getting one as schwag. I thought my Droid sucked and wasn't worth what I paid for it. If it had been free, I may have been more tolerant of it and wooed by the novelty factor.

<comment><USER3> I don't even know where to begin. Apple is the one that made the decision to stay with ATT so it's their own damn fault. As Apple loves to say, it's the end user experience that matters. Apple has stuck by ATT for two reasons: Control and Money. At a severe cost to users.

You think his opinion has less merit because he got it for free? That is just laughable. Brad Feld has more credibility and money than you or I will probably have in our entire lifetime. Completely irrelevant.

<comment><USER4> You may not know where to begin with your comments about the Apple and AT&T relationship, but that would mostly be because you Don't Get It. It's not just about control and money; these matter, but less than you think.

By choosing AT&T, Apple chose GSM, which gave the iPhone compatibility with most of the world. They looked at CDMA and realized that it was a dead-end technology; they looked at the expense of having to maintain two different radio chipsets; they looked at a lot of things and made the decision that, at least up until now, they didn't want to deal with it. Apple has relationships with three GSM carriers in Canada (Rogers/Fido, Bell, and Telus) and many more elsewhere in the world. If T-Mobile had used the more common GSM frequencies, Apple might not have gone with an exclusive deal with AT&T. Maybe.

On the other hand, my immediate reaction on seeing the story title was "who is Brad Feld and why should I care that he's switching?"

Seriously. Looking at his CrunchBase profile, I can see that he does VC stuff now and built a fairly large consulting company, but I am still not sure that I should care about his opinions about consumer electronics. So I _do_ think that his opinion has less merit because he got this particular device for free. (Money isn't credibility. To me, he's just some random guy with a platform. A blogger with no relevance to anything that I do.)

IMO, a consumer who has loyalty to a particular device or technology is a fool. If someone really comes up with something that I can unequivocally say is better than my iPhone, I will switch. So far, Android is "close but no cigar".

<comment><USER5> You are completely wrong. The expense of maintaining two different radios is nothing compared to the extra millions of devices they would have sold. This is so wrong that it is embarrassing that people use this as a point.

How much do you think it costs to buy a standard part, and hire a dozen engineers to get it all working??

<comment><USER2> _How much do you think it costs to buy a standard part, and hire a dozen engineers to get it all working??_

My experience with embedded hardware type startups would lead me to think you would pretty much double your FCC registration process/expenses, add about 50% overhead to your QA budget to basically test everything twice, add about 20% to your hardware layout budget (unless the two chips are highly pin and form- factor compatible), and a few other incidentals. On top of the other extra basic engineering code to "get it all working".

Then of course you also have to WANT to have the unit on the carrier that you added the CDMA chipset for in the first place.

The harder part to gamble on in a situation like this is: how many people will switch carriers to get a truly hot device? If you get it right (as Apple has appeared to), a large majority of people will pick the phone over the carrier. I'm sure they would have sold more iPhones to date than the current number if they had a CDMA version, but I'm not convinced it would have been a truly significant number overall.

Anyway, that's my rough experience with hardware design. What's your perspective on the added costs?

<comment><USER6> It's so expensive, they're not coming out with a CDMA iPhone this year.

Oh wait. They are? Huh. They must just have decided that the masses want iPhones. If they have to lose money on them... oh wait, you mean that isn't how business works?

</comment></comment></comment></comment></comment></comment><comment><USER7> It's great to have competition. For my needs Android is still a little too clunky in the UI department. I use it but I don't enjoy using it. Lots of simple things are made far too complex. For instance setting the action of plugging in a USB cable each time (or risking data corruption by not un- mounting the SD card) Using multiple e-mail clients because I have GMail and a separate IMAP server setup. The menu/back/home/search button setup is a bit awkward to me. Why have these extra buttons when you have a big touchscreen? I don't really like switching between the touchscreen and physical buttons constantly. It's not a smooth experience.

</comment><comment><USER8> We'll see whether he sticks with Android over the next few months or switches back. Even though he has some good reasons for switching, I think it really comes down to the fact that he got two free phones and might as well give them a try.

Also, as an investor, Brad can better do his job if he's familiar with both platforms. He doesn't really get at that in the post, but it seems to me that it should be an important concern for him.

</comment><comment><USER9> I'm getting a little tired of this "open" vs. "closed" debate.

Someone should ask Richard Stallman what he thinks about writing C# on Windows. There's only one platform on which the millions of lines of C# using Window's CLR are going to run well. Truly open means your software can run anyway, with a bit of effort. Mac software doesn't port well to Windows, native Windows software doesn't port well to Linux. Mac and Windows are walled gardens, they're just bigger gardens.

<comment><USER10> > I'm getting a little tired of this "open" vs. "closed" debate.

That's because it's not a debate. This isn't something that we are sitting around arguing about in the abstract. It's an actual real ongoing issue in the real world that affects people. The "debate" will go away when the issue goes away - either because Apple changes their policy or they get marginalised and turned into a minority player like they are in every other market. It looks to me like the latter is going to be what happens, but it didn't have to be that way.

<comment><USER11> "like they are in every other market" - last I checked, the iPod is doing pretty good.

The debate is happening with people who need things that the most of the people buying cellphones don't need. Will Apple modify its policies? Maybe,they have in the past. I think it more likely they will add carriers in the US before changing their policies. I really believe the last thing they want is the type of app on the iPhone / iPad that Mac's gets from Adobe.

<comment><USER12> Best-selling industry-standard applications?

<comment><USER11> I think the "fake" interface ways more heavily on Apple's thoughts then sales numbers.

</comment></comment></comment></comment></comment><comment><USER13> I'm having iphone/flash/android fatigue.

<comment><USER14> I was thinking earlier today how useless and tired these topics have become. Mentioning any of the three has too much potential to spark arguments that quickly devolve into gadget he said/she said. I don't know how anyone can read these with interest.

On a related note, can we just accept that some of these big name people will switch devices and we don't need to hear about it? They have the same complaints as everyone else, so does it really matter?

</brief rant and probably karma>

<comment><USER6> Especially since everyone has their opinion which is in some way tainted by which phone they have, which platform they like, or ultimately what things are more important to them day-to-day. Fundamentals and ideology - they will likely side Android. If it's all about UX then its Apple. There are merits to debate still and there are interesting arguments about how it will affect their market share, but everyone in these topics has pretty much already made up their mind. The conversation plays out the same way everytime...

</comment></comment></comment><comment><USER15> Where is Microsoft in all of this? We're almost at iPhone OS 4.0 and Android 2.2 and in the same time Microsoft have managed to ship one minor upgrade (6.5) and talk a bit about how great 7 will be.

<comment><USER14> Much like the search industry, this isn't exactly Microsoft's forte[1]. I think they see the benefit in shipping something fresh, given that they're not exactly at risk of going much lower.

1: <http://www.gartner.com/it/page.jsp?id=1372013> (see table 2)

</comment></comment><comment><USER16> I'm in the same camp. Loved the iPhone when it came out, then it slowly wore me down. Switch to the Droid was huge for me, and I cant even imagine using an iPhone again. As a hacker, droid just "feels better". More open, hackable, and solves almost all my key frustrations with iPhone (doubt I need to repeat them here, as they've been gone over to death).

iPhone is something I'd recommend to my mom. A droid is something I'd recommend to a coworker.

</comment><comment><USER17> And today I had a healthy bowel movement, followed with gas all dat.</comment>


Your gut is telling you what to eat – and you're not listening - <AUTHOR> http://www.vox.com/2015/8/3/9074927/food-hangover

<comment><USER2> Very interesting until I got to the word "toxins". At that point I stopped reading. Any time you use the word "toxins" my pseudo-science radar turns on and my ears/eyes turn off.

It turns out that the paper referenced was written in 1995 (yes, 20 years ago), in the Journal of Range Management which was discontinued in 2004 (11 years ago) ([http://www.researchgate.net/journal/0022-409X_Journal_of_Ran...](http://www.researchgate.net/journal/0022-409X_Journal_of_Range_Management)) it was an invited article (ie. probably not peer reviewed although I cannot tell for sure) and it appears that author has no medical training. The author "is currently a professor in the Department of Rangeland Resources." This professorship seems to have ended in 2008: [https://www.cnr.usu.edu/files/uploads/WILD%20Vitaes/Provenza...](https://www.cnr.usu.edu/files/uploads/WILD%20Vitaes/ProvenzaResumeCitations.pdf)</comment>


Show HN: Product configuration using three.js - <AUTHOR> http://jiekebo.info/embed/example/lego.html

<comment><AUTHOR> Hi there! This is an example product configuration, which is fully dynamic and adjustable using the admin panel on jiekebo.info. It is just a quickly made configuration of a toy character. The idea is that it should be possible to model any product with the admin panel, and have the dynamic product configurator display and align individual parts to give an idea to the user, the impact of part choices. Any feedback is greatly appreciated!</comment>


Show HN: Morton Filter: Fast, Self-Resizing Alternative to Bloom Filter - <AUTHOR> https://github.com/AMDComputeLibraries/morton_filter <comment><USER2> The paper[1] has a nice explanation of both Morton filters and the prior Cuckoo filters. I've read a bit about cuckoo hashing, and this seems like a natural extension of the idea.

[1]: [https://www.vldb.org/pvldb/vol11/p1041-breslow.pdf](https://www.vldb.org/pvldb/vol11/p1041-breslow.pdf)

</comment><comment><AUTHOR> A cuckoo filter is a Bloom filter replacement that supports deletions and which often uses less memory. This code base implements a Morton filter, a revamped cuckoo filter that is, respectively, up to 15.5x, 1.3x, and 2.5x faster for insertions, deletions, and lookups than the original implementation out of CMU. It uses a compressed block format that enables in-situ reads and updates on a logically sparse, yet compactly stored filter (i.e, without block materialization). It particularly excels when the filter is bigger than L3 cache. Morton filters also support self-resizing like a quotient filter but resize up to 20x faster. The research paper appeared at the 2018 VLDB Conference. A subsequent extended version has been invited to appear in the VLDB Journal.</comment>


Ask HN:  Is it possible to find a job in SF from Dallas? - <AUTHOR>

I've been looking for a job in San Francisco for about 8 months.  I've made it to the interview stage with several companies, but I've gotten no job offers.
I've heard some people say that it's much easier to find a job in SF if you live there.  Is it worth it for me to figure out a way to move there and then find a job?  The thing is... moving from Dallas to SF is expensive.  I doubt I have the money to put down as a deposit on an apartment and make the first month's rent.  Is it naive of me to wait in Dallas to find a job that will help with relocation expenses?  Or should I just make the jump and move to SF?  Are there any ways to make the move more affordable? <comment><USER2> You definitely should just come live in SF. You'll have a much better opportunity to network and meet potential employers. Everyday there is at least one event in the SF Bay Area for you to attend, whether it's a meetup, drinks, or hackathon you'll undoubtedly find work here faster if you're living here.

I can't speak to making the move cheaper since I moved out here for college with virtually nothing. If you're worried about the price of rent, you could consider living outside of the city. While living in SF is probably more desirable you can live south in places like Mountain view, Palo Alto, Daly City or over in the East Bay like Berkley, Fremont, etc. You'll easily be paying half your rent if you choose to live outside of the city. If you don't bring a car, or sell it when you get here you can still take BART or CalTrain into the city for events and for interviews.

Hopefully this helps. :)

<comment><USER3> I moved out here for college with virtually nothing. If you're worried about the price of rent, you could consider living outside of the city.

signature:[http://watch-life-unexpected-episodes-online.download- tvshow...](http://watch-life-unexpected-episodes-online.download-tvshows.com/)

</comment></comment><comment><USER4> I actually got a job in the Bay Area while living in Dallas three years ago. Recruiter found my resume on Monster.com and after two phone screens and flying me out, they hired me.</comment>


Kurt-Werner Wichmann - <AUTHOR> https://en.wikipedia.org/wiki/Kurt-Werner_Wichmann <comment><AUTHOR> From [0]:

> Only seven weeks later, on July 12, 1989, three blueberry collectors > discovered their bodies. [...] They went to the forester to let the police > know. On the way, they met a brown-haired, well-built, about 40 years old > man with a bag on his hand. The Kriminalpolizei assumes that this was the > perpetrator, who sought exactly on this day and this time more victims in > the Göhrde.

> On July 12, 1989, the day of the discovery of the second murder, the > 46-year-old housewife Ingrid Warmbier from Uelzen and a 43-year-old district > manager [...] drove together to the Göhrde.

> Two weeks later, on July 27, 1989, police officers from the requested police > unit in the context of a nationwide search for clues discovered the victims > of the second double murder by chance. The date of death could certainly be > dated July 12, 1989, the day the police began their investigation into the > location of the first murdered couple. The scene was located 800 meters from > the site of the first double murder.

Kurt-Werner Wichmann committed a double murder in a remote forest, met the discoverers of the bodies on their way back to notify the police, and _killed another couple a few hours later while the police was investigating the original bodies 800 meters away_.

[0] [https://en.wikipedia.org/wiki/G%C3%B6hrde_murders](https://en.wikipedia.org/wiki/G%C3%B6hrde_murders)</comment>


Ask HN: What should a student's résumé look like? - <AUTHOR> As many other CS students I've been applying for internships for several months now. Unfortunately I haven't had much luck in getting any interviews despite having what I feel is a pretty decent résumé. It currently contains a previous internship at a well-known tech company, several years of full-time and part time work as a developer, a profitable side project, and two popular open-source projects used by thousands of people.<p>I'm having a hard time deciding on how to improve my chances of getting interviews. What are tech companies looking for in an internship application? <comment><USER2> First of all, resume standards may depend on your country. I'll assume US.

* Start with your basic information (name, email, etc) and a short (as in 2 sentences) summary of what you're trying to achieve.

* List your skills and stick to technologies. Don't mention the whole "organized, fast learner, good team member" shit. It is unquantifiable and assumed from a professional. Everything you list should be briefly mentioned either as part of a past job XP, or a side project.

* List your work experiences. Use action verbs and highlight what you did and how it helped the company.

* List your side projects with links to demo and repo

* List your education.

Don't add the "hobby" section. nobody cares that you like rock climbing or walking your dog.

<comment><AUTHOR> Thanks for responding! I'm actually based in Europe although most companies I've been applying to are originally from the US.

I think I have all the things you mentioned except for the summary at the beginning. In my work experience I've been trying to put things into concrete numbers and to mention the technologies I've worked with.

Given what I mentioned in the post, do you think there is something I'm lacking in and should work to expand upon?</comment></comment>


Complete Guide to Electric Scooters - <AUTHOR> https://altriders.com/complete-electric-scooters-guide/ <comment> jerome-jh No mention that e-scooters usually lack brake power to be safe. Most only have a rear brake, which is much less efficient than a front brake for stopping, on any vehicle. But having a front brake on a scooter would be very unsafe as well, because it would be too easy to flip over the front wheel.

Conclusion: e-scooters cannot be made safe beyond 10mph/15kph.

Ever wondered why bicycles have large wheels?</comment>


Guide to Serverless Architecture - <AUTHOR> https://www.simform.com/serverless-architecture-guide/ <comment><USER2> I've built and maintain quite a large serverless system, with a large team of people, and most of these issues aren't really a big deal. Cold start is well- known and also has well-known mitigations (e.g. don't use the JVM, which wasn't designed for fast startup times).

I use AWS extensively, so I can elaborate on AWS's approach to these problems. Deployment is straightforward with CloudFormation, VPCs/security groups/KMS/etc. provide well-documented security features, CloudWatch provides out-of-the-box logging and monitoring. Integration testing is definitely important, but becomes a breeze if your whole stack is modeled in CloudFormation (just deploy a testing stack...). CloudFormation also makes regionalization much easier.

The most painful part has been scaling up the complexity of the system while maintaining fault tolerance. At some point you start running into more transient failures, and recovering from them gracefully can be difficult if you haven't designed your system for them from the beginning. This means everything should be idempotent and retryable--which is surprisingly hard to get right. And there isn't an easy formula to apply here--it requires a clear understanding of the business logic and what "graceful recovery" means for your customers.

Lambda executions occasionally fail and need to retry, occasionally you'll get duplicate SQS messages, eventual consistency can create hard-to-find race conditions, edge cases in your code path can inadvertently create tight loops which can spin out of control and cost you serious $$$, whales can create lots of headaches that affect availability for other customers (hot partitions, throttling by upstream dependencies, etc.). These are the _real_ time- consuming problems with serverless architectures. Most of the "problems" in this article are relatively easy to overcome, and non-coincidentally, are easy to understand and sell solutions for.

</comment><comment><USER3> Drawbacks I experience:

\- Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present.

\- Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up.

\- Security/monitoring: having fewer functions make this less of a worry, but it's still difficult and it's clear that there's not much of an ecosystem and best practices.

\- Debugging: this can be really annoying. I can usually avoid this by having a proper local testing setup (see below), but when that doesn't cut it, this gets annoying.

Drawbacks I haven't really experienced:

\- Statelessness: this is probably due to not splitting up my code in too many functions, and thus not having that much complex interactions, but this hasn't really been a problem for me.

\- Execution limits: haven't run into them yet.

Drawbacks I've managed to contain:

\- Local testing: I'm writing Node Lambda's. Since they're just stateless functions, it was relatively easy for me to write a really simple Express server, transform the Express requests into the API Gateway format, and convert the API Gateway response format back into Express format. This works fine for local testing, and reduces the effects of vendor lock-in. That said, I do do a lot of the request parsing in the Lambda function itself, rather than letting API Gateway do this.

\- Deployment: this is actually pretty sweet. I'm using TerraForm which, although it's a bit immature and thus cumbersome to set up, has been getting the job done and allows me to easily deploy new copies of the infrastructure for every branch of my code.

\- Remote testing: as mentioned above, deploying it for every branch I have allows me to see what it's going to look like in production.

Hmm, perhaps I should turn this into an article sometime...

<comment><USER4> > \- Vendor lock-in: although I try to minimise this and have a clear picture > of where the lock-in lies, it is very much present.

The post isn't loading so I don't know exactly what it's in reference to (AWS lambda, the framework, the more generic idea?). But, the serverless framework[0] supports all major cloud providers (AWS, Google, & Azure) as well as self-hostable options like OpenWhisk and Kubeless.

[0] [https://github.com/serverless/serverless](https://github.com/serverless/serverless)

<comment><USER5> I may be naive (or just witless), but don't you kind of end up with vendor lock-in to serverless itself?

The first step in their example is "login to your serverless account".

<comment><USER4> You have to make a choice at some level of the stack, for me, that was serverless as the deployment framework. You could probably use terraform or ansible + some custom scripts, but then you could argue you're locked into terraform or ansible ;)

The login thing isn't actually necessary (or if it is, that's new)

</comment></comment></comment></comment><comment><USER6> CGI scripts with a new name. Lambda and the like are interesting but any system is a composable set of components.

You can say the same about Object oriented programming or func programming. separation of concerns but on the network. Server functions arent a panecea cause you still have to manage all the other pieces.

An elegant thing would be your entire app is in that single lambda but without state there goes your db. even so, people cant resist taking something and adding and adding more to it.

<comment><USER7> More like CGI scripts with a loadbalancer that promises to run your application on a host with enough memory within at most 600ms. That solves an actual problem with CGI scripts, but I really would love to see more tiers with lower latency brackets, sub 10 milisecond should be doable for certain lambdas and costs.

<comment><USER8> The other key component of serverless is the pricing scheme: pay for what you use; don't pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog.

Interestingly lambda seems to make async IO technologies like nodejs less compelling, because throughput capacity isn't really relevant anymore.

<comment><USER9> > The other key component of serverless is the pricing scheme: pay for what > you use; don't pay for provisioned capacity.

There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane.

If I have autoscaling with an upper bound, I can stay within a fixed budget per month. If I reach my budget, yeah no more new servers, but whatever running keeps running. My business doesn't disappear, I get business continuity. Paying based on % of traffic sounds insane. How will I plan for business continuity if my monthly budget is reached with this kind of model? (without any "minimum xx requests" kind of crap free tier, business continuity means fixed upper bound _AND_ continuing service, not _OR_ )

<comment><USER10> I don't know if platforms already support it, but there's no reason why you can't have a throttle (calls/minute).

<comment><USER11> I can't speak for all serverless platforms, but AWS API Gateway does support throttling and burst throttling[0].

[0] [http://docs.aws.amazon.com/apigateway/latest/developerguide/...](http://docs.aws.amazon.com/apigateway/latest/developerguide/api- gateway-request-throttling.html)

</comment></comment></comment></comment></comment></comment><comment><USER12> The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to:

      * Manage/deploy servers
      * Monitor/maintain/upgrade servers
      * Figuring out tools to deploy your app to your server
      * Scaling an app globally.
      * Coping with outages in a data-centre/availability
      * Worry about load-balancing & scaling infrastructure

<comment><USER13> This is exactly what PaaS's like Heroku have been doing for years, right? Isn't Lambda just an even more locked-in PaaS?

<comment><USER14> Heroku is a bit higher level. If you're using heroku, you're using their blocks and their methods of passing traffic, logging, etc. With lambda, it's just a function. You have to connect everything yourself, not you can do it exactly the way you want.

<comment><USER15> You can redeploy a Heroku app to many other servers and platforms relatively easily.

However, I'm not sure you can do the same with AWS Lamda Functions. To mean, this means it is like a lock-in.

<comment><USER14> It's just code with basic function entry point. You may get your parameters and configuration in a different way, but not much else changes. There are only so many ways to call some code.

</comment></comment></comment></comment></comment><comment><USER16> > Drawback of Serverless: Vendor lock-in, statelessness, local testing, > cold/warm start perf, security, deployment, execution, monitoring, remote > testing, debugging.

Excuse me? Let's use lambda for what it was meant to do, not replace your entire stack.

<comment><USER17> But 'serverless' has a much nicer ring to it than 'serverfewer'...

<comment><USER18> "Serverfewer" sounds like the title of the next Neal Stephenson book :-)

<comment><USER19> I think you meant "Serverevres" :D

</comment></comment></comment></comment><comment><USER20> I tried the excruciating task of building a real-time multiplayer game with server-side authority using only Firebase and Google Cloud Functions.

Basically I handle all the logic in Firebase rules and lambdas. Any destructive action goes through a GCF that updates the Firebase Realtime Database. Actions that happen often (like moving) are updated directly by the client but validated with some overly complicated Firebase rules.

It's very nice not having to worry about servers and scaling, but it can be a really painful development experience.

Let me know if you want to try it out and I'll post the URL.

<comment><USER21> That sounds really cool. I'd like to check it out.

Now that you've been through it, would you do it again? Or stick to a more traditional architecture?

<comment><USER20> You can play it at [https://tombs.io/](https://tombs.io/)

It's pretty much a collaborative and social experiment where I wanted to explore the concept of using in-browser cryptocurrency mining as a monetization and bot fighting method (something I had a problem with in the original Ludum Dare entry it's based on). That's a different discussion though. (You need to manually start the mining and you can explore the map without doing it. It's only when digging and chatting it's required.)

I'm actually planning on rewriting the whole backend in a more traditional Node.js + WebSockets stack so no, I probably wouldn't do it again for this type of application. However, I will probably use it again for other things.

<comment><USER22> I get this from your site:

Security risk detected: Trojan.Gen.NPE

<comment><USER20> Thanks! I presume it's the Coinhive script that triggers it. What antivirus software do you use?

<comment><USER22> symantec endpoint protection ... ? (I'm at work)

</comment></comment></comment></comment></comment></comment><comment><USER23> For me the BIGGEST gain of using serverless architecture is security. For example, this year I started two ecommerce platforms. One's a digital delivery e-shop - selling ebooks, training and stuff and the other is a physical delivery e-shop. Normally, I'd write my own Phoenix/Rails app, but this time, I decided to go serverless for my furniture shop and wrote it all in Jekyll. Yes, the static site builder. I use netlify to manage the production aspect of it (which IS pretty AWESOME) and simple excel sheets to track inventory (which is what my vendor provides me, anyway). For payment, I simply use the checkout/cart functionality provided by Paypal and all this just works! The site is designed in such a way that you can't even tell anyway what's being used for the backend. No one can tell it's just a bunch of static HTML pages on display.

Whereas, for my digital delivery store, I regularly need to check my logs to see if anyone's doing anything suspecious. For example, a lot of IPs randomly try to visit wp-login.php or /phpmyadmin. Maintaining a production web application is a full time job by itself, if you don't have a team.

Having said that, many people would immediately assume static page builders are generally dumb. That isn't exactly true - You can automate a lot of stuff. For example, my local machine has a custom Jekyll plugin for my store that resizes and optimizes product images before pushing to prod to keep the page load time small. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Or maybe write some code to communicate with an third party API and usually, it's not free.

End of the day, I make sales and that's all that matters. That's when it hit me hard that my customers needn't care nor know what's behind their favorite site.

<comment><USER10> If static sites are now also Serverless, the word has lost all meaning.

 _IF I had chosen the Rails /Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere._

Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.

<comment><USER24> "Serverless" is itself a bit of a misnomer. The point seems to be to distribute stateless sub-computations. Whoop dee doo. At some point you need a "server" to modify application state. A static site has no state modifications, so it actually is serverless in this sense of having stateless computation.

<comment><USER10> I get it, but while the name is not very good, there's a reason why it came about now, despite the fact that we've had static website hosting for decades. It was coined to describe a particular kind of service, and retrofitting it makes it less useful and more prone to confusion.

</comment></comment></comment></comment><comment><USER25> > grouping a bundle of functions together behind an API gateway, you've > created a microservice

Always beats me why people don't warn the readers about the almost impossible nature of logging and monitoring such systems :/

<comment><USER26> Because most devs aren't the ones that will need to worry about how it's going to be monitored once deployed. Not to mention troubleshooting a billion micro services when something breaks.

<comment><USER27> How do you figure that? Who else should worry about it?

</comment></comment></comment><comment><USER28> What I've found having to use serverless is the local development tools are broken. You'll find cloudformation is the only way to reliable manage all the proprietary paid for services which will require you to read several documentation on various tools (kinesis, dynamodb stream or fifo, standard queues) to work out which one might work. To find out it doesn't necessarily work in your applied function (CloudWatch Insufficient Alarms I'm looking at you). So you then have a choice to use cloudformation and another deployment tool to push your services. This is more typical after you've given up trying to manage dynamodb-local across platforms for your codebase.

</comment><comment><USER29> One thing I would like to see in articles like this are more concrete use cases for using serverless. The article begins talking about the concept as though you should write your entire app in serverless, and then in their case study, use serverless as a background process to convert image types.

The other use case I always come across is image scaling.

I'd be interested if anyone would like to share their use cases as entire apps or background processes.

<comment><USER19> Well, I'll add my own use of serverless.

We use Lambda + API GW to manage the glue between our different data/service providers. So for instance we expose a "services" API (API GW) that takes a request, does some business logic (lambda code), calls the relevant provider(s) and returns the aggregate response. That principle can (and probably will) be extended to hosting our own back-end / business logic.

We're trying to get to the point where a dev only needs to write a Swagger file, the lambda code and a bit of configuration, and the rest is taken care of by AWS and our CI framework.

<comment><USER29> Very cool, thanks for sharing. The last part about just writing Swagger, Lambda, and a little config is very interesting.

Do you worry about vendor lock in, which is coming up a lot on this comment section?

<comment><USER19> we're a small start-up, so I worry about shipping as fluidly as possible, and being confident that my infra just runs (security, patch management, scalability, uptime, etc.) All of which serverless gives me much more easily, and at a lower cost (for now) than running my own EC2 instances. I'll worry about vendor lock-in (or dumping serverless for that matter) once I start to get ridiculous bills from AWS, or hit performance issues, or whatnot. But I try to mitigate by relying on standard formats (Swagger) and keeping my code as close to the business logic as possible - which is fairly easy with Lambda. The only thing that is really tied to AWS is the framework we use to build and deploy the architecture: a large Cloudformation file basically. We explored Serverless (the app) to manage this, but it didn't fit our need (in particular, Serverless has apparently never heard about Swagger, so that sucks).

</comment></comment></comment></comment><comment><USER30> Page doesn't load... maybe they need a server...

</comment><comment><USER31> I'm looking forward to Amazon Fargate which is less extreme than Lambda but still server less in some sense. Basically you can still write proper apps (Spring Boot apps in my case) but, so long as you containerize them, you don't have to provision servers, just tell Amazon what resources they need and how many instances you want.

</comment><comment><USER32> This article needs more exclamation points.

</comment><comment><USER33> Is this supposed to be comedic? It seemed comedic to me in several places. Is that the joke?

</comment><comment><USER34> Only Google and Amazon exist in this write-up? This is not a guide, more an intro.

<comment><USER35> Who are some other providers, aside from self-hosted?

<comment><USER36> Microsoft has Azure Functions, if you're in to that kind of thing.

</comment></comment></comment><comment><USER37> It's redirecting to their homepage. Am I missing something?

<comment><AUTHOR> You might want to use a VPN, sometimes organizations enable geo filters.

<comment><USER37> Wow, you were right!

</comment></comment></comment><comment><USER38> Be more concise.

<comment><USER24> TFA is unintelligible mumbo jumbo describing an architecture that amounts to (I think!) minimizing statefulness and moving all stateless computation out to a cloud.

Well, OK, but how about some examples? How about some advice as to where to draw lines? E.g., if the computations take less time to do on a server than to distribute, then maybe don't?</comment></comment>


Ask HN: How Google, Microsoft, Amazon, IBM Shortlist CV's? - <AUTHOR>

I am very interested to know that how Tech giants shortlist CV's. Do they look for specific keywords in CV or  your linkedin profile or you github profile or you blog What they look in a applicant to be shortlisted to interview call.<p>If you are recruiter kindly do explain your process as well
Thanks <comment><USER2> They never had my cv before the technical interview. I had participated in one of their code jams and was contacted to gauge my interest and setup a technical interview.</comment>


Breaching Identity in 5 Minutes or Less (for non-programmers) - <AUTHOR> http://mittermayr.tumblr.com/post/30099422061/breaching-identity-in-5-minutes-or-less

<comment><AUTHOR> I just discovered an even more obvious and easy to automate way. Pick random words, like "newyork", and MD5 them. Then search for them on Google (or elsewhere), adding a whitespace and then "@gmail.com" or "@hotmail.com" or whatever. It'll show a list of accounts who have used "newyork" as their password with a web-service once, and possibly their e-mail account as well.

as a programmer, all logic and simple. but it still is really scary.</comment>


Modes, Quasimodes and the iPhone - <AUTHOR> http://ignorethecode.net/blog/2009/07/02/modes-quasimodes-and-the-iphone/

<comment><USER2> This article does not talk about Vi vs. Emacs. Is the title editorializing?

<comment><AUTHOR> Yes it is on purpose. The idea is to think about the more general theme of editing modes, not the discussion about the iPhone the article narrows the topic to.

<comment><USER3> You cite a piece detailing how the use of unseen modes makes interacting with a computer difficult and infer this as a boon to a strongly moded editor that offers nothing resembling the sort of modeless simplicity the author was advocating. The saving grace given in the article for modes was that they be evident and easily disabled and that they be fully under the control of the user to toggle on and off.

Emacs modes come closer to this than vi. When you type it enters text at the cursor. All special modes are entered via holding key chords. Modes which are not done at the end of the chord are generally recorded in the status line so it is evident they are active.

At any rate, the piece, having nothing to do with this traditional browser debate, though of token interest in itself was slighted by your title used to link it.

</comment></comment></comment><comment><USER4> From the article "Modes are not always bad. (1)Modes cause issues if they make computers behave in unexpected ways. However, if the modes themselves are obvious to the user, (2)if it is always clear how to exit the current mode, and (3)if the modes interfere with as few of the user's actions as possible, these issues disappear."

VI screws up in all of this (1) (2) and (3).

<comment><USER5> I agree with this, but I would also say that Emacs "modes" are equally confusing, and much more widespread.

</comment></comment><comment><USER6> A better title would have been 'On the iphone, VI has better usability than Emacs' cause the iphone by itself can't really prove usability on anything other than itself. Apples and Oranges.

</comment><comment><USER7> In general, people like emacs for its programming environment and vim for its ease of use after familiarity. So... the title's a bit misleading?

</comment><comment><AUTHOR> If quasimodes are a hindrance to usability, than Emacs is full of these, but I never thought of them that way. Maybe it is different on the desktop an Vi is the perfect editor for the iPhone?</comment>


Between the Lines: LA parking spaces - <AUTHOR> http://www.lamag.com/features/Story.aspx?ID=1568281

<comment><USER2> _The garage—designed to serve the public good—instantly made the Metro immaterial to concertgoers, placed several thousand cars on the road every week, and pumped a few hundred tons of carbon dioxide into the atmosphere each year._

I'm an LA native, and this is what I hate most about my city. There are sections of the building code that literally mandate a minimum number of parking spaces when you build a new building. When every building has plenty of parking, everyone is expected to drive everywhere. As long as this is the case, there is no incentive to improve public transportation.

<comment><USER3> Here's another good quote:

"Single-car garages, hidden in backyards and alleyways in the early 20th century, doubled in size by the 1970s and moved onto the front lawn once cities began to require two residential spaces for every house."

The LA city requirement that new houses must have parking for two cars, side- by-side, has pretty much made the only possible home layout like this:

[http://image.americanhomeguides.com/cgi- bin/imagemgr/get_ima...](http://image.americanhomeguides.com/cgi- bin/imagemgr/get_image?image=832bed1e1f4626ee5de7cee343be8dfe)

i.e., driveway straight up to garage, which is in front of house. This means the front yard is half concrete, and every (new) house front is dominated by the garage.

Even relaxing the requirement to allow tandem parking would be an improvement.</comment></comment>


Turn your foursquare check-ins into a travel diary - <AUTHOR> http://foursquare.esplor.io/

<comment><AUTHOR> The site works best with foursquare, but you can link it with lots of other social media accounts to import data

</comment><comment><USER2> Does this only work with foursquare?</comment>


NOLOH (not one line of html) Beta Program - <AUTHOR> http://www.noloh.com

<comment><USER2> I think this is a valid direction for a large category of problems--many complex applications on the web probably should use almost nothing but JavaScript for the "view" layer in the MVC paradigm, from a maintenance, usability and performance perspective. While I'm a big fan of using the simplest possible solution to any problem, and HTML is the simplest solution to almost every website problem, there's also a large class of problems where HTML templates just don't make sense--they're just an unmaintainable mess.

Applications where the UI is always dynamically generated based on the user, the state of the application and data, etc. are probably far more comfortable using JavaScript generated by code. Obviously others are going this route, as well. GWT uses programmatic generation of UI elements, for example, though it does so by compiling Java down to JavaScript (kinda).

I'm not going to rush right out and start using nohloh (I don't enjoy working in PHP, and most of my work is on existing apps), but I certainly see value in the idea. And, in fact, most of my work lately has been on converting a huge application to be friendly to using almost nothing but JavaScript for the front-end (it's an installable systems management app, so I don't have to worry about spiders at all, and the UI was never template based as it is dynamically generated based on all of the criteria mentioned above).

Anyway, looks pretty neat.

</comment><comment><USER3> I'm noticing some snarky comments, which seems to be a theme now when people post their creations. I don't think HN is the best place for those. Valid, constructive criticism seems a lot more appropriate here.

<comment><USER4> There is a new breed of user here at HN, and with that, a reaction in the older users.

I find this site seems to be more trafficked than it was previously, but the noise to signal ratio has gone through the roof.

<comment><USER5> The reddit tone starts to predominate. There has been about 4 threads to address the SEO issues, where a "read existing comments first" then vote-up and "answer in the thread" was the appropriate thing to do.

The part of non-technology related stories has increased trendemously, when some people point it as "non-HN", there are answered the Community Card (they forget Community and Common are two very close words). PG is non-existent has a spoken moderator who tells the rules when it's appropriate to do so (his absence is eminently suspect).

More importantly, a lot of the old users keep their mouth shut now, some have completly disappeared for obvious reasons. Most of them are prolly still reading HN but the idea of posting a comment has become tiring for them. The battle is already lost, but not for everybody.

</comment></comment></comment><comment><USER6> I love it! A web application which actually feels (for the most part) like a well designed and implemented desktop app.

Two minor quirks: Back and forward button cause an ugly sort of refresh. And I forgot what the other one was because it just looks and feels so nice.

I hope this type of stuff gets more widespread. I also hope that browsers don't screw it up, as they're likely to. (Works well in Firefox 3 for me)

<comment><USER7> You're right. We have something in the works that will make back and forward refresh only the necessary parts, but that's a feature for a future build. Thanks for the compliments!

</comment></comment><comment><USER8> This actually looks interesting.

Any chance you could show the PHP source to the doc viewer page <http://www.noloh.com/Docs/#/section=apireference> ? I'm assuming that's a NOLOH application which would give everyone a more substancial idea of what it's really like to work with your class hierarchy.

<comment><AUTHOR> We actually plan to open up the entire noloh.com, and noloh developer zone as soon as we finish documenting and adding features. The current developer zone was thrown together in a few minutes.

Throughout this month you'll see it evolve into what we think will be the most easy and intutive developer documentation experience, at which point it will be open for all to see and use.

</comment></comment><comment><USER9> This is really awesome.

Constructive comment: I can't middle click links to open them in new tabs.

P.S. You're not getting too much enthusiasm for it here because of the choice of PHP. I can assure you, though, if this takes off, a lot of those "can someone build me a Joomla or Drupal site?" on eLance will rapidly turn into "can someone build me a Noloh app?"

<comment><AUTHOR> Thank you for the kind words.

You're right about the tabs, that will be implemented in the next update to the website. We're planning to release Ruby and Python versions of NOLOH at some point.

<comment><USER9> If the framework does all you promise and starts getting adopted, you could make the language translation an open source project, maybe. That way it will both be quicker to completion and less error-prone (since you're not locking yourself in). In any case, it doesn't seem like turning this into Ruby or Python should be too much of an issue, since they're all OOP languages anyway.

</comment></comment></comment><comment><USER10> Changing your browser's font size breaks things in interesting ways as well due to the co-ordinate system being based on pixels.

<comment><AUTHOR> In your application you can specify the be based on whatever units you prefer. We chose px as the default and use it in most places, however you could easily change the base unit to whatever you wish.

</comment></comment><comment><USER10> For when you absolutely, positively need to ensure no search engine ever sees any of your content.

<comment><AUTHOR> A completely SEO application is rendered to search engines. NOLOH applications know when a search engine is visiting and when it's a normal user. This is all described in detail in the features section.

<comment><USER11> There is a risk such differential-serving will trigger search-engine 'cloaking' penalties.

<comment><AUTHOR> The search engine gets all the content, at the same url and ip address, but in a way that's optimized for it. There's no redirects, or other cloaking methods involved.

<comment><USER11> I've tried browsing as 'Googlebot'. The text returned is better for a crawler than nothing (or just Javascript), but isn't the sort of functional and dense link-structure that most helps site rankings.

Also, the crawler-friendly URLs are different from the URLs the search engines will see reported by users' toolbars or discover on inlinks from other sites. So various link- and traffic- based contributions to rankings are likely to suffer on Noloh-style sites.

<comment><USER7> There can be a dense link structure, depending on several factors. For example, NOLOH itself generates a file that keeps track of possible paths through your application. After we simply upload a newer copy of the file on the live server, NOLOH will generate more links to the search engines. Also, I'm not sure I understand what you meant by your last sentence, but links for search-engines can be used by users too.

<comment><USER11> To explain:

I browsed a few clicks in as 'Googlebot'. Rather than typical website links with many targets, and useful anchor-text, each page had only one substantive link, with minimal query-string-like anchor-text (like "section=features").

If a bot reached the URL "<http://www.noloh.com/index.php?section=features>", and then that URL appeared as a search result, and then users visited by that URL, they would then (upon navigation) find themselves at odd composite URLs like "[http://www.noloh.com/index.php?section=features#/section=bet...](http://www.noloh.com/index.php?section=features#/section=betaprogram)".

Meanwhile, if crawlers discover inlinks from other sites that users have copied and pasted, like "<http://www.noloh.com/#/section=whoweare>", a crawler will only see this as a link to the root page.

Your pagerank is going to be diluted over these arbitrarily different URLs, and traffic analysis via toolbar reports is not going to boost key target pages as strongly as in an application with traditional stable URLs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I have no real idea how search engines work when they index a page, but I would assume they do not execute any of the Javascript, just grab the text based file from the server and analyze it. (does anyone have any insight into this?)

So I was pretty excited to try it until I realised that if that is the case - this is probably the worst SEOed site I have ever seen, it literally has no SEO.

Its a good idea, but personally after the usability of a site, it being nicely SEOed is really, really important.

<comment><USER7> NOLOH generates only the content (text, images) for search engines so they won't get any JavaScript or anything extraneous like the styles for their text.

</comment></comment><comment><USER13> It looks interesting, but what's the deal with Bubble2.0-ish "Register for the Beta program"? Why not just let anyone download the source and install it, assuming that's the way people will eventually use this?

You don't need to commit to any type of support, you'll probably get a lot of useful feedback and, if it's good, some free publicity too.

<comment><AUTHOR> We're currently doing a beta program hosted on our server so that we can provide support to the users, as well as make sure they always have the latest version of the NOLOH Kernel for their applications. This will help us communicate with the sandbox users, and get quality feedback from them. This is especially necessary because our documentation is far from perfect, so while we're actively working to create more docs, examples, and videos, we can still get valuable insight and feedback from a small group of serious developers.

<comment><USER13> Eventually is this going to be some sort of hosted service or a framework users download, like Rails or Zend Framework?

If it's the former, please ignore my comments :) If the latter, I for one would be playing around with the code right now if there was a download link... A few examples in a README file would do fine for now. Release early and often, as they say ;)

It would be hard for users to do significant work with NOLOH when the code is hosted on your own server and updated automatically, possibly breaking code they added.

<comment><AUTHOR> We plan to offer free hosted, free download, as well as commercial hosting and download options. Currently NOLOH is being used in several major companies (ex. CIG) for their website in addition to their internal applications.

The Beta Program is setup to allow us to work closely with a small group of developers so that we can help them develop their applications in NOLOH. If any updates during the beta program break an application we will work with the developer at our cost to fix the problems.

We have lots of documentation, articles, videos, etc, to put together before we can offer it to non-commercial users which is what we hope the beta program will help us accomplish.

</comment></comment></comment></comment><comment><USER14> With JS off, I get an error page. With JS on, there is nothing displayed. The source is rather plain. Is this a joke?

<comment><AUTHOR> If you have JS off you should be directed to an error page. Could you please elaborate on "With JS on, there is nothing displayed". Viewing source on a NOLOH application will not give you anything of interest.

<comment><USER14> The page is completely white. Nothing there. Fx3.0rc_1.

</comment></comment></comment><comment><USER15> The very definition of cloaking is serving different pages to bots then users. So the 'optimized' stuff is essentially cloaking... What prevents googlebot for using a different header to check if the site is cloaked?

Btw, i prefer haXe (haxe.org) as a true unified web language ;-)

<comment><USER7> Yes, cloaking is giving a user and a search engine different pages, but the purpose of cloaking is to decieve search engines, and that's why it's evil. With NOLOH, search engines aren't decieved, they are simply given the content in a way that they can understand since they do not understand JavaScript. They're still given the same content (same text, images, etc...) but they're not told to modify the DOM since they can't. So it is a helping hand to search engines, not a deception in any sense. Why would googlebot use a different header to pretend that it is a user in order to recieve a broken page? That would not benefit any party.

haXe is only unified in the sense that it has support for JS, Flash, and a few other languages. But going through their tutorials (for example, <http://www.haxe.org/doc/js/ajax>) you still see that you have to write mark- up. So all of the traditional problems that NOLOH is designed to address still persist in haXe. Mark-up is static, error-prone, not intuitive for application development, interpreted by browsers differently, and the list goes on and on...

<comment><USER16> > Why would googlebot use a different header to pretend that it is a user in > order to recieve a broken page? That would not benefit any party.

Well... it would benefit Google (and its users), because they could detect and punish cloaking. How would Google detect cloaking? A clerk examining the two served versions, or automagically comparing the two versions of served content? How smart would their comparing algorithm be? Could it determine that your site was not being deceptive? How would you write such a algorithm (and it better be generic, and difficult to exploit)?

Basically, I have no idea what the hell Google does and does not do, but I am scared (and ignorant) enough to always serve search engines _exactly_ what I serve users.

</comment></comment></comment><comment><USER17> I once built an app similar to this, where all the dom elements were built by the script. Good concept, but I thought the search engines handed out penalties for displaying different facets to robots vs users?

<comment><USER7> It's the same content that is sent to spiders and users, but the robots just get it optimized and without anything extra like JavaScript or styling elements. They get text, images, and links, which is all they want anyway.

</comment></comment><comment><USER18> What's up with the name? It seems very difficult to say and get people to understand what you mean. Noloh! No-loh! It's a strange name.

<comment><AUTHOR> NOLOH, pronounced no-low is an acronym for Not One Line of HTML.

</comment></comment><comment><USER19> This looks fairly similar to Seaside to me. Of course, you have the advantage/disadvantage (however you want to see it) of using PHP.

<comment><AUTHOR> Dan Shafer who has authored books on smalltalk, as well as evangelized seaside for some time has this to say on NOLOH: <http://www.danshafer.com/onemind/node/813>

</comment></comment><comment><USER20> none of the links work for me. just briefly says "loading," then nothing happens. NOLOH: Nothing Online Loading Or Happening.

<comment><USER20> nevermind. seems to be working now...

</comment></comment><comment><USER11> With JS on in FF3, I see the front page... but nothing that I click brings up anything else... nor do I have the right-click open-in-tab option I prefer.

NOLOH == Not One Link Opens Happily?

<comment><USER11> FYI, it works in FF2, IE7, and Windows Safari. So it's apparently a Firefox 3 issue.

<comment><USER6> Works in FF3 for me.

<comment><USER11> Still no luck for me -- even quit and restarted, and cleared cache. Oddly, though, it's working on a FF3rc1 install I have on a Ubuntu machine.

Tried viewing traffic in Live Headers and script in FireBug to see what was going wrong; attempting a direct fetch of one JS URL fetched came back with a script that was just a comment: "/ _~NScript~_ /".

<comment><USER21> _"... Still no luck for me -- even quit and restarted, and cleared cache. ..."_

Do you use NoScript?

<comment><USER11> Not in the FF3-on-Windows install for which Noloh doesn't work.

Add-ons installed there are Firebug, Live HTTP Headers, Tree Style Tab, and User Agent Switcher.

</comment></comment></comment></comment></comment></comment><comment><USER22> i like how, if you block the cookie, the whole site just fails to load.

<comment><AUTHOR> We're working on a cookieless version. Over the past 4 years it wasn't an issue with any of our clients as it's expected for a user to have cookies enabled. However we are aware of this issue and will be addressed in a future releae.

</comment></comment><comment><USER23> this is horrible for SEO purposes, as I think google ignores most code.

<comment><AUTHOR> NOLOH programs are automatically optimized for SEO, try <http://totheweb.com/tools/spider-test/index.php> and type in noloh.com.</comment></comment>


Harjeet Taggar: "excited to be joining the y combinator team" - <AUTHOR> http://twitter.com/Harjeet/status/7682943155 <comment><USER2> PG: Is this true?

<comment><USER3> It seems unlikely to be false, though perhaps a misunderstanding is possible since we're working with 140 characters. I expect there will be an official announcement/confirmation sometime in the future.</comment></comment>


Ceph 1.3: A Tentacular Release - <AUTHOR> http://f2.svbtle.com/ceph-1-3-a-tentacular-release

<comment><AUTHOR> Sebastien Han is showing how to install 1.3 (and other versions too) using Ansible here:

[https://www.youtube.com/watch?v=dv_PEp9qAqg&feature=youtu.be](https://www.youtube.com/watch?v=dv_PEp9qAqg&feature=youtu.be)</comment>


Hackers can cause explosions in oil and gas facilities - <AUTHOR> http://www.homelandsecuritynewswire.com/dr20130729-black-hat-event-highlights-vulnerability-of-u-s-critical-infrastructure

<comment><USER2> [http://www.youtube.com/watch?v=UhNWwFu1Qjs](http://www.youtube.com/watch?v=UhNWwFu1Qjs)

DefCon covered this topic (albeit tangentially). The link above actually shows several power plants (IIRC they were dams, but drowning vs blowing up, IMO it's a draw) and that one can control the system remotely. All of the systems that are shown ONLY had the default User/Pass on a control system exposed directly to the internet.</comment>


Hövding Invisible Bicycle Helmet - <AUTHOR> http://www.coolhunting.com/tech/hovding-invisible-bicycle-helmet.php

<comment><AUTHOR> And how it works : <http://www.hovding.com/en/how/></comment>


Plugins in C - <AUTHOR> http://eli.thegreenplace.net/2012/08/24/plugins-in-c/

<comment><USER2> Why not export a struct with function pointers like everyone else? You should take a look at how VST plugins are implemented.

You load the dlo, call a function passing in your own struct of application functions and get back a struct of plugin functions. No weird naming conventions needed, easily version-able. Tried and true.

<comment><USER3> I don't know whether this was the author's intent, but it's better to start simpler (not in designs but in concepts - arguably, structs are simpler than funky naming conventions) for the beginner and less experienced dev. The struct method is a powerful one, yet not one grokked simply by the neophyte. There probably needs to be a Part II.

<comment><USER4> On the contrary, setting up a regime of specially-named functions is error- prone and clunky, and structures with function pointers are a language idiom in C, and, finally, if you're too new to the language to understand function pointers, you can't use either technique, because both rely on function pointers.

Ultimately, the real problem is that teaching bad designs to people because they're new to the language is counterproductive.

</comment></comment></comment><comment><USER5> On a related note: Be wary of the dlclose() function, it may not necessarily free any resources[1] and not every libc implements it correctly[2].

1\. <http://www.openwall.com/lists/musl/2012/08/20/1> 2\. <http://www.openwall.com/lists/musl/2012/08/23/20>

<comment><USER4> If you really need to demand-load and demand-unload lots and lots and lots of plugins --- and that's the only design I can think of where dlclose matters, but maybe there are others --- fork a plugin host process from the main process, and kill it off when you're done with the plugins. You can use anonymous shared memory to communicate between the two processes (since there's a simple parent/child relationship).

</comment></comment><comment><USER6> Here's the link to the intro article, all in Python3.

[http://eli.thegreenplace.net/2012/08/07/fundamental- concepts...](http://eli.thegreenplace.net/2012/08/07/fundamental-concepts-of- plugin-infrastructures/)

</comment><comment><USER7> "While C itself is a relatively rigid language"

</comment><comment><USER8> I use libpeas

bye</comment>