Bayesian Optimization for Collaborative Filtering with MLlib - <AUTHOR> http://blog.sigopt.com/post/148703071378/sigopt-for-ml-bayesian-optimization-for <comment><USER2> Wait, Spark has built-in Model Hyperparameter selection ([http://spark.apache.org/docs/latest/ml- tuning.html](http://spark.apache.org/docs/latest/ml-tuning.html)), that was not mentioned in the article. What advantages does your service do?

Relatedly, why are you advocating using MLLib/RDDs when they have been deprecated in favor of ML/DataFrames ([http://spark.apache.org/docs/latest/ml- guide.html](http://spark.apache.org/docs/latest/ml-guide.html))?

<comment><AUTHOR> Great questions!

The Spark hyperparameter selection uses an exhaustive grid search approach, which can take a long time (complexity grows exponentially with number of parameters to tune) and produce poor results when compared to other methods [1]. Bayesian optimization is a great way to tune time consuming and expensive functions like ML pipelines, where finding a good configuration in a small number of total attempts is the only tractable way to tune the system.

ALS implementation in MLLib still requires ratings in RDD and hasn't moved over to ML/DataFrames yet.

Edit: Looks like the original comment was edited, but this post does in fact use the built in MLlib ALS implementation.

[1]: [http://arxiv.org/abs/1603.09441](http://arxiv.org/abs/1603.09441)

<comment><USER2> > ALS implementation in MLLib still requires ratings in RDD and hasn't moved > over to ML/DataFrames yet.

ALS has been available in ML/DataFrames since 1.3.0, per the documentation. ([http://spark.apache.org/docs/latest/api/scala/index.html#org...](http://spark.apache.org/docs/latest/api/scala/index.html#org.apache.spark.ml.recommendation.ALS))

> Edit: Looks like the original comment was edited, but this post does in fact > use the built in MLlib cross validation methods.

I edited the comment to correct my error that ALS was not mentioned as being native to Spark. However, for Hyperparameter cross validation, I looked at the code in the repository ([https://github.com/sigopt/sigopt- examples/blob/master/spark/...](https://github.com/sigopt/sigopt- examples/blob/master/spark/recommender_sys/src/main/scala/MovieLense.scala)), and while the Spark CrossValidation function is imported at the beginning of the Scala file (from ML, not MLlib), _it is not used in the code_ , in favor of SigOpt.

I'm confused.

<comment><USER3> Thanks for pointing out the switch away from RDD, looking at the master branch for MLlib in github it looks like ALS is still using RDDs? [https://github.com/apache/spark/blob/master/mllib/src/main/s...](https://github.com/apache/spark/blob/master/mllib/src/main/scala/org/apache/spark/ml/recommendation/ALS.scala)

Admittedly I'm not a spark expert though, thanks for bringing this up!

<comment><USER2> MLlib is for operating in RDDs, ML is for operating in DataFrames.

RDDs themselves, however, are obsolete to DataFrames as DataFrames are faster and cover most of the functionality of RDDs for common use cases.

<comment><USER4> RDDs are not obsolete. The reason dataframes are faster is exactly because they are more restrictive than RDDs. If you need to run arbitrary code, RDDs are stil more flexible.

<comment><USER5> Since every dataframe has a lazy instance of rdd, and several methods on dataframes simply call the corresponding method on rdd ( eg. foreach ), I am not sure about the faster bit of your assertion.

<comment><USER6> They are _faster_ in the sense that many thing you previously had to do in a RDD lambda are now Dataframe operations (which are optimized by the Catalyst compiler).

So if you want to do one of the operations in the sql.functions package[1] then Dataframes (and Datasets) are very valuable.

If not, then they won't give you much benefit. However, you will get a little improvement because the Tachyon out-of-JVM-memory framework[2] which I don't think RDD version has access to.

[1] [http://spark.apache.org/docs/2.0.0/api/python/pyspark.sql.ht...](http://spark.apache.org/docs/2.0.0/api/python/pyspark.sql.html#module- pyspark.sql.functions)

[2] [https://dzone.com/articles/Accelerate-In-Memory- Processing-w...](https://dzone.com/articles/Accelerate-In-Memory-Processing- with-Spark-from-Hours-to-Seconds-With-Tachyon)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I could give a shit about the hyperparameter tuning (CV... it Works For Me) but your writeup of Gaussian processes and why they are called kriging in spatial stats is awesome.

[http://blog.sigopt.com/post/130275376068/sigopt- fundamentals...](http://blog.sigopt.com/post/130275376068/sigopt-fundamentals- intuition-behind-gaussian)

<comment><USER8> Dear apathy (love the name), I wrote that post and am really glad that you liked it. I had another more recent one that focused on a different topic but had a solid paragraph right at the beginning that also stepped through some of the history. It might be useful because it had a bunch of links trying to join content between GP stuff, kriging and RKHS. It is linked below. Have a great day.

[http://blog.sigopt.com/post/147952139093/sigopt- fundamentals...](http://blog.sigopt.com/post/147952139093/sigopt-fundamentals- breaking-free-of-the-grid)

<comment><USER7> Great post. Why is the kernel trick so important for Gaussian processes? My understanding is that operating in an RKHS is primarily needed to enable that cute little maneuver.

Wait, never mind. If GPR is like an infinite-dimensional linear regression then doing it within an RKHS means you don't actually have to bother with the functional generalization and can get solutions to a potentially ill-behaved loss function along a grid/cube/hypercube/whatever. Is this part of why SigOpt works more efficiently than classical parameter space sampling designs?

Not-so-ninja edit: Time for me to re-read Rasmussen, I think.

<comment><USER8> There's a couple different points there, so lemme see if I can answer each of them.

First off, the use of the term "kernel trick" appears, I think, primarily within the machine learning community. It refers to the idea that some other (likely more useful) representation of the data of interest exists, but that the representation might be in a much larger, or even infinite-dimensional, space. Fortunately, in the context of certain algorithms such as support vector machines, that representation never appears by itself ... it only appears when inner-producted (not a word) with another such representation associated with some other piece of data. For certain representations, that inner product can be represented by a reproducing (also called positive definite) kernel, and thus can be computed without ever forming the larger representation. This concept appears in Wikipedia [https://en.wikipedia.org/wiki/Reproducing_kernel_Hilbert_spa...](https://en.wikipedia.org/wiki/Reproducing_kernel_Hilbert_space), both for the Hilbert space inner product and for the Mercer's series representation. Unfortunately, as is the case with a lot of higher math on Wikipedia, it's more useful as a reference for an expert than to get you rolling on a new topic.

As far as kernel methods in general, those pop up all over the place, including in the context of Gaussian processes. Gaussian process regression (GPR), also called kernel-based approximation in the numerical analysis community, is one great example of that. I generally try to think of it not as an infinite dimensional linear regression method, but rather as a constrained optimization problem. There are infinitely many functions that pass through a given set of data, thus asking for the "one" is ill-posed ... I am interested in the most well-behaved one. We define the behavior of a function as its RKHS-norm, and the function that minimizes that norm, but still respects the observed data, is the solution to the GPR problem.

Regarding why SigOpt performs better than a good old-fashioned grid, that can be for multiple reasons. Probably the most important one, at least in my mind, is that SigOpt is not trying to create some perfect model of the function at hand - SigOpt is only interested in optimizing that function. That drives every decision we make, and actually it is something I often need to remind myself of because I grew up in approximation theory. A basic design of experiments is interested in understanding how the function works everywhere, but we can save some expense by more swiftly discarding regions unlikely to contain the optimum.

As far as why RKHS in particular work very well - that deals with the optimality theorems underlying approximation using reproducing kernels. Assuming you have a reasonable function on a reasonable domain it probably belongs to a RKHS - such functions can be represented very effectively by an appropriate kernel. Now, determining that kernel can be a complicated task (maximum likelihood estimation or cross-validation are common tools) but if you have an acceptable kernel you can make strong statements about the quality of the model. Because the quality of the model is constantly improving, the GP-backed optimization tool is constantly providing a better representation of the true function, and thus pointing towards the optimum more quickly.

There's another more fundamental reason why searching on a grid in higher dimensions is trouble, and it deals with the fact that the ratio of the volume of a sphere and of a cube with the same radius decreases as the dimension increases. This means that there is increasingly much volume away from the center of a box in increasingly many dimensions. Using a grid to try and fill that space becomes unacceptably costly. Of course, Gaussian processes have their own issues for larger problems (>30 dimensions, maybe) but SigOpt has more than just Gaussian processes behind the scenes. Also, there have been improvements over the years in GP performance in higher dimensions (for example, [http://epubs.siam.org/doi/abs/10.1137/10080138X](http://epubs.siam.org/doi/abs/10.1137/10080138X)).

There's some pretty solid notes for graduate students on this topic at [http://math.iit.edu/~fass/590/](http://math.iit.edu/~fass/590/). That was the class I took to first learn this stuff as a student and I've tried to contribute back to them over the years. It comes at the topic first from the math side, not the stats side, but there's some stats stuff in there as well. Chapter 8 of those slides contains that theorem regarding the minimum-norm interpolant.

Hope that helps.

<comment><USER7> Reading the slides now, my goodness a lot of things just became clear to me. What a wonderful collection of pearls. Thank you for "giving back" to the topic in this way.

</comment></comment></comment></comment></comment><comment><USER9> So SigOpt was tuning rank (number of latent factors), number of iterations to run the algorithm (in my experience alternating least squares generally converges within 10-20 iterations, but there'd be no downside to running it longer unless it's overfitting), and the regularization strength.

What optimal parameters did it find for these?

<comment><AUTHOR> Great question. As you point out, all of these parameters (rank, num iterations and the actual reg. term) can in some way contribute to the regularization of the reconstruction of the ratings matrix. We thought it would be interesting to include all of them and here are the optimal parameters SigOpt found for this experiment:

rank = 36

numIter = 30

log_lambda = -2.90405347693

</comment></comment><comment><AUTHOR> I'm one of the co-founders of SigOpt (YC W15) and am happy to answer any questions about this post (or anything about SigOpt).

More info on the methods behind SigOpt can be found at [https://sigopt.com/research](https://sigopt.com/research).

</comment><comment><USER7> Oh, also, for students: [https://sigopt.com/edu](https://sigopt.com/edu)

I'm worried this is going to be like good Scotch for me.

</comment><comment><USER10> There is package, mlrMBO, created by the great guys who created mlr (absolutely awesome for building pipelines, you will ditch caret in a second!). Not on Spark obviously, but thought some might find it useful.

[https://github.com/mlr-org/mlrMBO](https://github.com/mlr-org/mlrMBO)

</comment><comment><USER11> How does SigOpt compare to GPs?

<comment><AUTHOR> Great question. SigOpt is a hosted, scalable ensemble of different Bayesian optimization methods. Many of these methods use Gaussian Processes (GPs) as part of the modeling aspect of their Sequential Model Based Optimization (SMBO). We've written up a primer on Bayesian optimization [1] that goes over some of the different methods, with lots of citations for diving deeper.

We've found that SigOpt compares very favorably [2] to other Bayesian optimization approaches. In addition to this, our hosted platform allows people to harness the full power of GP backed Bayesian optimization with just a few lines of code [3] instead of the sometimes heavy administration required by other methods.

[1]: [https://sigopt.ninja/1470077644/pdf/SigOpt_Bayesian_Optimiza...](https://sigopt.ninja/1470077644/pdf/SigOpt_Bayesian_Optimization_Primer.pdf)

[2]: [http://arxiv.org/abs/1603.09441](http://arxiv.org/abs/1603.09441)

[3]: [https://sigopt.com/docs](https://sigopt.com/docs)

<comment><USER11> Thanks. Do you guys do any meta-learning based on information from optimization runs on the many instances that SigOpt runs on? E.g. if Alice uses Sigopt for a neural net architecture and Bob does too, is the information from Alice's run used to improve Bob's?

<comment><AUTHOR> We don't explicitly share information at the experiment level like that for privacy reasons. All user data is explicitly isolated from other users, on top of the fact that due to the black box nature of our optimizer we often do not know what the underlying method or system being optimized actually is.

We do, however, run a rigorous evaluation framework [1] over our methods as we iteratively improve (and compare to other techniques). This allows us to build up our ensemble of optimization strategies to most efficiently tackle problems that are most important to our users. As we see users leveraging our service for certain types of problems (like mixed continuous/categorical + failure regions) we do try to incorporate them more into our testing, roadmap, and ensemble, but only at the meta level.

[1]: [http://arxiv.org/abs/1605.06170](http://arxiv.org/abs/1605.06170)

</comment></comment></comment></comment><comment><USER12> [https://sigopt.com/pricing](https://sigopt.com/pricing)

\- Individual: $1,000/month

\- Enterprise: Custom pricing

I am not a multi-million $ company, so I guess it's useless for me.

<comment><AUTHOR> We have a free academic tier as well: [https://sigopt.com/edu](https://sigopt.com/edu)

</comment></comment><comment><USER3> Post author here, happy to answer any questions as well.</comment>


The case for raising chickens in virtual reality - <AUTHOR> http://www.vox.com/2014/5/19/5729182/the-case-for-raising-chickens-in-virtual-reality

<comment><USER2> Or we could just treat the chickens well.</comment>


Why Kids Care More About Achievement Than Helping Others  - <AUTHOR> http://theatlantic.com/education/archive/2014/06/most-kids-believe-that-achievement-trumps-empathy/373378/

<comment><USER2> If you read the law for Danish public school system ("Folkeskole"; [http://www.uvm.dk/Service/Publikationer/Publikationer/Folkes...](http://www.uvm.dk/Service/Publikationer/Publikationer/Folkeskolen/2010/Faelles- Maal-2009-Elevernes-alsidige-udvikling/Folkeskolens-formaalsparagraf)), you find that one of the goals is to "contribute to the understanding of the interactions between people", and intellectual freedom and democracy are important concepts.

Reality might be different from the law, of course. Listening to my children (10 and 13 years old) and their friends, I find that they in general try hard to understand other children and wish to play/work as a group.</comment>


Show HN: A new way to buy, sell, and exchange used stuff - <AUTHOR>

I just launched my first startup and need feedbacks from HN on how to grow a video classified ads website.  We're focusing on helping people advertising their second hand stuff via videos instead of photos.  Any suggestions are appreciated.
http://www.123exchanges - Connecting buyers and sellers with video. <comment><USER2> You must be one of the few startups launching with ASP.NET! ;-) (assuming you aren't doing anything funny with extension rewrites!)

How to help grow? Well, it looks like you've already got link sharing for facebook and twitter - how's that working? Seems that would be a great way to get more exposure and people interested. You've got the sbux gift card, you've got bonus points for referral...how long have you been up and running??? It __seems __to me you've done a lot of things right! Oh, and the site looks great too!

Have you reached out to those who have listed on your site to get their feedback about the experience? Or, have you gone to garage sales or the like and asked people what it would take to get them to use your product?

How about this: Have you scanned listings on craigslist, reached out to the seller, and offered them free listings to give it a shot and get feedback? Maybe target a specific area, like cars, or iDevices, and really hit it hard.

How about mobile apps? Native iOS or Android app that initializes the camera, records, allows me to provide the meta data (description/price), gets from the phone my location to save me that hassle, and then post it all from the app? That would be pretty convenient!

<comment><AUTHOR> The website has been up for around 2 months. Sharing on Facebook and twitter have mostly been friends and families. We are in the process of going to yard sales offering them to list their products with us for free (probably we even have to do the recording for them). We have reached out to sellers on craigslist but it didn't go so well because they thought we were spammers. We are planning to reach out to pawn shops and used car dealers. As for the mobile app, we are working on getting one as soon as possible to make the process much easier for people to upload their listings. Thanks for your feedback. You gave me a great idea of having to do all the dirty work (uploading video, creating a store, marketing for the users) at the beginning.

</comment></comment><comment><USER3> I love the video aspect...but if Ebay decides to adopt a similar strategy?

As I was going through your site I thought of a somewhat ridiculous concept, but I figured as an entrepreneur you would be open to any possibility. I guess I'm just one of those people who love brainstorming about exciting possibilities, even if some of my ideas are completely infeasible!

As I was going through a few videos, I noticed varying levels of production quality and video review styles among sellers. Perhaps a way to homogenize the experience is to offer individuals a service where they send you their stuff and your company can handle the video reviews (maybe add a distinctive flair to them) or even do a little product testing in addition to actually selling their goods for them. The premise is to completely take the item off the seller's hand and not have him/her worry about it.

I can probably list a dozen problems with this idea off the top of my head (and maybe there are already services like this??), but hey, you never know what may change down the road!

Anyway, best of luck with your venture!

<comment><AUTHOR> Thanks for the feedback. We are working on building a system where we will do all the dirty work for our users.

</comment></comment><comment><USER4> Clickable:

<http://123exchanges.com/default.aspx>

Didn't you post this here some weeks ago? If memory serves me right, you've made some (significant?) changes to the home page payout since then - I think it is much better now.

All the best.

<comment><AUTHOR> Yes. I made a revision to the website. Thanks

</comment></comment><comment><USER5> Do you have an Android or iPhone developer on your team? Can I submit video's via my phone? Love the concept! Focus: phone adoption.</comment>


Performant Front-End Architecture - <AUTHOR> https://www.debugbear.com/blog/performant-front-end-architecture <comment><USER3> Not to be too negative, but I'm seeing a lot of purely anecdotal comments on HN with lots of fuzzy gut feelings and very little to back up what seemingly amounts to elitism against JavaScript.

It's very easy to write fast JavaScript, with React or pick-your-framework. I would argue that these frameworks go out of their way to help you do that. But carelessly throwing modules at your problem is not going to get you that.

There are many reasons why SPAs can be slow. Whether that is due to truly lazy developers, overly tight deadlines, or management that just doesn't care is often left out of these discussions.

Everyone likes to complain about SPAs, as if terrible load times are a fundamental trait of frontend frameworks. That is not at all the case.

<comment><USER4> > Everyone likes to complain about SPAs, as if terrible load times are a > fundamental trait of frontend frameworks. That is not at all the case.

I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. _Of course_ the result is buggy and slow.

The browser already has a UI and DOM framework. Use it. (Yes, I know it's ugly. Such is life.)

<comment><USER5> Depends on the target audience. Many customers will be sold on how pretty an app is, sometimes to the point of overlooking missing features. Having a good looking app becomes a competitive advantage, and therefore important to spend time on. Such is life.

<comment><USER4> Your point is orthogonal, even if true. My point is that SPA frameworks are necessarily buggy and inefficient - after all, their whole point is to reimplement in a bespoke fashion the stuff that the browser already implemented.

Buggy and inefficient stuff sometimes makes sense to a business, this is true.

<comment><USER6> That's a common misunderstanding and absolutely not true. They are abstractions and not reimplementation, and in practice can help achieve way better performance than what would naively come out. React is _not_ a particularly good example of that.

They also solve problems like state synchronization and mutations that the browser has zero facilities for. As mentioned in another comment above, in any medium sized project you'll have implemented more than half a framework abstracting the DOM already.

</comment></comment></comment></comment></comment><comment><USER7> How to optimise front end apps? Don't use pure javascript based frontend. Do all normal crud apps on regular server side code. Eg. A normal rails CRUD app is much faster even with the intermediate page loads factored in, than a heavy react app with a spinner to make it appear fast. Want to give the feel of a JS app? Use turbolinks. Really want to use something fancy and dynamically update your content from the server? Use something like Phonix Liveview. I love VueJS and React. But these days I've switched to using Liveview so much that I don't miss them at all. The benefits are also huge. Near instant updates with very little server load (scalable) and ultra-light frontend. Win win win.

<comment><USER8> Semi-related and backend agnostic is Intercooler.js:

[https://intercoolerjs.org/](https://intercoolerjs.org/)

It's just AJAX and HTML fragments.

</comment></comment><comment><USER9> Front-end performance optimization is surprisingly lacking when it comes to web apps. We focus so much on shaving off 50 ms when it comes to server response time, but we're fine with a 7 second load time for front-end. It's very surprising that there isn't as much focus on front-end architecture performance.

<comment><USER10> In my experience, it's OK to have a (slightly) longer load time for content behind a login wall. I also spend extra effort caching whatever I can for return visits. Refreshing the page should give you an almost instant load time.

<comment><USER11> I wonder if you've actually talked to any users, or this is just your personal opinion.

I hate load times for apps, especially as I know it should be instant and all sites I architecture load instantly.

<comment><USER10> Yea, I've run user feedback sessions. Page loads never come up as a complaint (plenty of other things to complain about :P)

The goal was to keep an average of <3.0s for the first meaningful paint, after login. Before login, all pages were treated with the same respect you'd treat any marketing page; render what you can as fast as you can.

Back with AngularJS, when code-splitting and lazy-loading modules/controllers wasn't an option, you had to get creative. Since moving to Vue, initial page load has never been an issue.

</comment></comment></comment></comment><comment><USER12> > In practice you'll rarely be able to optimize on all fronts. Find out what's > having the biggest impact on your users and focus on that.

Can't agree more. If your engineering team spent several sprints to focus on improving the app load time, it has to be something highly impactful on your conversion rate. Otherwise it's just a waste of resources.

<comment><USER13> This is very shallow short term view on things. Performance also impacts customer retention, loyalty, satisfaction and word of mouth advertising because of that, makes engineers feel good and proud about the things they do, rewarded and motivated to keep going and not leaving to do something else, etc. Hardly "a waste of resources".

<comment><USER14> Is it worthwhile making a page load 10x faster?

If you go from 10sec to 1 sec, absolutely.

If you go from 1sec to 100ms, maybe.

If you go from 100ms to 10ms, unlikely.

Assuming "fast enough for a good user experience", expecially early on in a product lifecycle, I prefer to focus on development speed than product speed.

<comment><USER4> In 2020, a webpage that "only" takes 10 seconds to load is a miracle of performance and user-friendliness. Load times of up to a minute are the new normal.

I'm pretty sure dismissive comments such as yours lead us to this bad place.

<comment><USER15> What webpage that you frequently use takes up to a minute to load? I can't think of a single one I've used over the past year.

<comment><USER4> Open the developer tools and see for yourself.

Of course by "load" I don't mean TTFB, I mean actually loading the full page, including all the spinners, reflows, banners and toolbars popping into your page, images, etc.

<comment><USER15> Why does that matter?

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I spent the last 6 months optimizing front end performance at my last workplace.

What I can say is measure before just blindly following a checklist.

Chrome devtools performance and audit tools are awesome.

Measure, fix biggest bottleneck, repeat.

This post has some great recommendations but things could be simpler. Like use http cache headers instead of service workers. They help both the cdn and the browser. Use immutable urls for assets.

The best way to improve perf is to simply load less JS and CSS. Less is more. It's not always possible but helps trim down large swaths of network load when you can keep things simple.

</comment><comment><USER17> What a goldmine. We should put together an endless checklist of best practices for all parts of webdevelopment.

So many apps are lacking, so many built on outdated/inferior tech. Currently there's just too much knowledge to consume.

<comment><USER14> I love checklists but you may end up with people dumbly following them.

That may be good when a checklist is accurate.

Unfortunately models work in the constraints and simplifing assumptions they were built in.

"Web development" it is a pretty large subject to cover. Best practices for dynimic site that is image heavy do not match best practice for systems that is heavy in static content.

A check list for web delopment is going to be pretty messy if you want to account of all cases.

But maybe it is worth giving it a try...

<comment><USER18> Include an item on the performance checklist about not blindly following items on the performance checklist.

Now nobody who follows the checklist completely could be doing so blindly.

</comment></comment></comment><comment><USER19> I'm surprised I haven't seen nuxt (an SSR framework for Vue.js) mentioned here. It makes many of these performance enhancements out of the box.

It enables some cool options, like pre-rendering static content with the generate flag. You can use it as a static site generator, or wrap dynamic stuff in a <client-only> component and only that portion will be rendered client-side.

Service workers & PWA stuff, code splitting and dynamic routes, its all made pretty easy.

I've been finding it quite easy to build performant front-ends with nuxt. It is opinionated, and it abstracts away the webpack config, so it certainly isn't perfect for everything. But for me, it has really been hitting a sweet spot.

</comment><comment><USER20> I greatly dislike the use of "performant" as an adjective.

The first sentence uses "fast and user-friendly" which is much clearer.

<comment><USER21> Oh man, I hate to be negative, but this word is my #1 pet peeve in tech today. It's becoming more and more prevalent and is driving me crazy. Why do people keep using this non-word? What do they think it means, and why? It's pure jargon, at best. The word's meaning is completely ambiguous and loosely implies numerous qualities without actually committing to any of those potential meanings. Does it load fast? Consume little memory? Respond promptly/clearly to user input? Do an acrobatic dance?

When someone uses this word, I can't help but feel that they are trying to gain the approval/validation of people who like to hear that something "performs well", without having to support the assertion with any concrete substantiation.

<comment><USER22> It is a word _because_ people keep using it. That's where words come from. Apart from the number of characters, it is no better or worse than other words/phrases having the same meaning. Sometimes the precise meaning is clear from the background context. Sometimes additional details need to be supplied outside of the title or bullet point where it is used.

What does "it" mean above? Devoid of context, it could be just about anything.

<comment><USER21> I understand the concept of "it's a word because people use it" \- but what does it actually mean? No one can give a consistent defininition because it's nebulous jargon with no clear or specific meaning. Without fail, every single usage is obfuscating or otherwise hiding the intended meaning.

Check out this Unity blog post I just came across: "Achieve beautiful, scalable, and performant graphics with the Universal Render Pipeline"

What exactly are "performant graphics"? Does that mean high frame-rate? High- poly? Extremely vibrant colors? HDR? Can run on a 486 with software rendering?

It doesn't tell me anything, and is essentially "vocabulary clickbait" \- it "sounds good", without really communicating anything. This is why I despise this word.

<comment><USER22> In context, I would expect "performance" to refer to how quickly a scene can be rendered, and another buzzword, "scalable", to refer to the size and complexity of scenes that can be drawn. "Beautiful" probably means "lots of detail and snazzy effects."

Actually, the article says "scalable across platforms", which is confusing to me. Maybe they mean scalable to different screen sizes?

</comment></comment></comment></comment></comment><comment><USER23> My favourite performance advice, regardless of context: just do less stuff.

In this case - load fewer and/or smaller resources.

<comment><USER24> As sensible as that is in a general sense, this article is actually heavily about dependencies and making sure the latency between when the browser knows about dependencies is small.

</comment></comment><comment><USER25> "Establishing a new server connection usually takes 3 round trips between the browser a server:

DNS lookup

Establishing a TCP connection

Establishing an SSL connection"

This takes more than three roundtrips and I wish the author would have mentioned 0-RTT options in quic and TLS 1.3

</comment><comment><USER26> I don't know what/how Fastmail does it but their front end is amazing. So fast. I assumed their name was about speedy delivery but the whole UX is the fastest I've ever seen.

</comment><comment><USER27> > The service worker below caches the HTML and CSS that's needed to render the > page.

Why would you need a service worker for this? Doesn't the regular browser cache achieve the same thing?

<comment><USER28> With a service worker, you can stream the header part of a new document instantly from the service worker, while fetching the content. That essentially makes an instance first paint.

I don't think that's what the example is showing, though.

<comment><AUTHOR> Oh interesting, I didn't know about stitching the streams together in the service worker!

Do you know what the advantage of that is over serving the full cached HTML page layout and then fetching the content HTML from inside the page?

</comment></comment></comment><comment><USER29> last year the React team presented a pattern called fetch on render, combined with proper code-splitting, I see this as a win-win for webapps

<comment><USER21> Do you happen to have any link on a presentation or post about that? I did a quick search and couldn't find more about it, though maybe it has a more specific name or something? No worries if you don't know offhand, just curious :)

<comment><USER30> Try the first four videos here:

[https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_...](https://www.youtube.com/playlist?list=PLPxbbTqCLbGHPxZpw4xj_Wwg8-fdNxJRh)

<comment><USER21> Ah nice, thanks!!

</comment></comment></comment></comment><comment><USER31> Modern front-end architecture has "fixed" the 1 second page load and replaced it with a 0.5 second page load... And a 3 second spinner... And a 1 second spinner... And a 4 second progress bar... But hey the TTFB is under 1s now!

<comment><USER32> This is such a tired old meme that conflates bad architecture with current professional standards. Bad architecture of anything has existed since forever but some bad apples don't spoil the barrel. Page render should occur within the first 300ms and page load should be complete in a second.

<comment><USER33> "Should" being the key part of your comment: it's quite rare in practice. Most SPAs are lucky to have page render in 2-3 seconds, or fully loaded in 10 - <USER2> my experience is using the latest iPhone in a major metro area around 10 ms from most major CDNs.

<comment><USER34> Yeah it would be great to see some numbers from anyone who might have them. I'd put money on SPAs being slower, inside the bell curve than, than the average traditional page load app.

<comment><USER35> SPAs don't make sense if it's not an 'application', but wouldn't a SPA be faster over time not having to reload the whole page and all that duplicate markup? Wouldn't the simple JSON calls be smaller than refetching and rerendering all of the HTML? Front-end application offer more than just no- reload though, like push notifications, real-time data, and offline caches.

<comment><USER33> It's not that simple: you need to factor in size and latency, too. If my SPA loads 2MB of JavaScript and then makes 50 API calls, it's going to be a lot slower than the server sending 20kb of HTML in a single response.

JSON may or may not be smaller or faster: if you have to load data you don't need or, worse, chase links it'll be worse. GraphQL may help but that's bringing it closer to server-side performance, not exceeding it.

Things which aren't possible otherwise are the best argument for SPAs, but another approach is progressive enhancement: you can load quickly and then load features as needed rather than locking in a big up-front cost if all you need are real-time updates or push notifications. There's a spectrum of capabilities here and there won't be a single right answer for every project.

</comment></comment></comment></comment></comment></comment><comment><USER36> 5 second page load is fine. This endless tuning is a great analytical puzzle, but implementing a new feature trumps these complex micro-optimizations that the consumer less and less about, with mobile having already become the common case access (mobile access is already going to be slow from network anyway). It's rare that you get a complaint. Once it's loaded and you have cached as much as possible, you're fine for returning customers which matter more to appease.

<comment><USER37> 5 second page load is not fine. Having the page load in 5 seconds is an annoying experience that causes you to lose users -- Amazon lost 1% revenue for every 100ms in page load time: [https://www.gigaspaces.com/blog/amazon- found-every-100ms-of-...](https://www.gigaspaces.com/blog/amazon-found- every-100ms-of-latency-cost-them-1-in-sales/).

<comment><USER36> > 5 second page load is not fine.

That analysis is from 10 years ago. Again, the landscape is different and spending time on this is a borderline foolish discussion (interesting from a technical perspective). It matters if you are the owners of a business, in the mass-retail space. Save yourself the time, add to your features or verticals.

Yes, 5s is still fine.

<comment><USER38> 5s is a pretty shit standard to set and in general customers or visitors that you lose to poor website won't tell you about it unless it directly impacts them. Also laughable that 5s should somehow become more acceptable even though we have better tools, faster networks, and faster hardware on all fronts.

It seems like your argument isn't that it's fine across the board, but rather that it's tolerable in a few circumstances. If I try and load a website that is packed with _features_ but loads slowly and maybe has a choppy experience, I'm going to go somewhere else if I can. It's only in the few circumstances that you can't go somewhere else will you be relatively fine.

<comment><USER39> Is 5 seconds an initial load, or every time the user clicks a button or menu item?

Business to business app, or sales site?

YMMV. 5 seconds could be intolerable, or a big improvement.

<comment><USER38> That's kind of what I was trying to describe there.</comment></comment></comment></comment></comment></comment>


Ask HN: As a unicorn data scientist, how do I transition to a manager resume? - <AUTHOR> I've got a weird profile.
I'm a Ph.D. data scientist who has worked at a FANG. But for unusual reasons, I've got plenty of management experience, perhaps to the degree as if I had worked as a project manager or management consultant during all my tenure in the industry.
As a result, it's possible my profile could be present as a golden genius unicorn. It's equally possible it could present like poser trash.
So how do I write up a resume I can use to apply to employers? Currently, I'm not even sure how to write up a resume for a management role in tech, much less perform the gymnastics to craft my data scientist profile into a resume for management.
Can anyone shoot me a manager or project manager resume that looks civilized?
email: firstname.lastname@example.com <comment><USER2> I sent an email - feel free to call me to discuss.

</comment><comment><USER3> Any interest in working for a bank in the UK?

<comment><AUTHOR> I'm absolutely happy to talk. From your comment history you seem to be genuine and open-minded, and do some interesting fintech work.

I couldn't find your contact info on your profile, so maybe you can shoot me a message on the email in the post.</comment></comment>


Deadspin pivots to non-sports coverage as owners demand shift to sports - <AUTHOR> https://twitter.com/AndyBCampbell/status/1189215243454636032 <comment><USER2> Deadspin, on it's own, was and is a profitable vertical. This story is completely about mismanagement and an unbelievably dumb calculation of believing the strength of a media brand is unrelated to its contributors. Further, don't ever confuse private equity for something more than it is: in nearly all cases, it's designed to suck out blood, saddle it with debt, and leave things in ruins. Ask Sears.

Please read this for more background: [https://theconcourse.deadspin.com/the- adults-in-the-room-183...](https://theconcourse.deadspin.com/the-adults-in- the-room-1837487584)

It's an absurd and ridiculous shame what is happening to them, and while I know this is HN and HN is connected to YC, that thin-skinned vampire Thiel is at lease partially to blame.

<comment><USER3> "Partially to Blame"

Blame is the wrong word I think...I would say "partially to thank" for ridding the media world of Nick Denton's coin-op libel mill, which had been tempting fate for years.

</comment></comment><comment><USER4> Good on the journalists still there.

What's crazy about this situation is that the site was already successful. Some rich people bought a website with an audience so they could extract money from it, but apparently didn't understand the concept of "devoted team."</comment>


Ask HN: Harvard or Stanford undergrad for Computer Science? - <AUTHOR>

I know there're a few threads about this (here and on other sites) but I wanted to get your specific advice. I'm mainly choosing between Harvard and Stanford for an undergrad program. I'd major in computer science, but maybe take courses in quantitative economics, cognitive psychology, pure math, etc.
I know Stanford being close to SV is a huge plus - but I'm not sure how much that matters as an undergrad. I have a startup idea I've been researching for the past 4 years, but it's nowhere near VC stage anyway.
I also know Stanford's computer science department is stronger - but I'm not looking to be a highly technical person. I can't see myself (or most other undergrads) "running out" of CS courses at Harvard, and if I do, I guess I'd be able to supplement them with MIT courses.
And then on the other hand, most of the top kids I know from top science competitions (like Science Talent Search) are heading to Harvard. I feel like I'd learn a ton from being around those types of people (especially those who aren't interested in comp sci), which is a plus on the Harvard side.
So Stanford has stronger CS, better weather, better ties for tech entrepreneurship, but Harvard has a more diverse education, several top science competition students, and better financial aid. Any advice? <comment><USER3> Looks like you just answered your own question.

Do you prefer stronger CS, better weather, and better tech ties or diverse education and non-CS science fields?

I'd say Stanford is much better for CS than Harvard though, right after MIT.

<comment><AUTHOR> Thanks for your help - it's definitely a tough question to answer. While I love CS and I'm sure I'll do something CS-related, I'm concerned that tech firms will look down on a Harvard CS degree as compared to a Stanford CS degree.

I already have strong research and a few good publications in CS-related fields, so I'm not sure if I want to continue the same vein of research or branch out in college.

<comment><USER4> The only real difference for getting a job today with a Harvard vs Stanford job is that you might actually have to look for employers versus the employers coming to you. Obviously nobody knows what the job market will be like in 4 years.

<comment><AUTHOR> Hmm, that's true, but it may differ by field. For example Goldman recruits much more heavily at Harvard than Stanford, but small startups recruit more at Stanford. I think my problem is I don't know what I want to do yet - <USER2> split between finance or entrepreneurship, or even pure research :P

</comment></comment></comment></comment><comment><USER5> Are you planning on interning while in school? That would probably be significantly easier (especially at a startup that possibly can't afford to pay as much) if you were in SV.

Not that there aren't internship opportunities at Harvard, but I believe there are more near Stanford (with no evidence to support it, so feel free to ignore me).

<comment><AUTHOR> I'd definitely like to intern - my plan is to do 1 internship at a big company (Google, FB, etc, which would be doable from Harvard or Stanford) and then at a small company (which would be easier from Stanford) and finally at a finance firm (which would be easier at Harvard for Wall Street-esque, and probably a wash for VC-esque).

But then again, Boston has a pretty good startup culture - what I think is interesting is the ratio of prospective startups to prospective funders in each city. Thanks!</comment></comment>


Ask HN: Any startups looking for a free marketing guy? - <AUTHOR> I'm in my last year of school and looking to help out a startup to gain some more experience. <comment><USER2> Unlikely, as you've done a rather poor job of marketing yourself.

1) The title for this doesn't make sense. Obviously, we can tell that two ideas conflicted, but a second read-over would have caught this.

2) You list no qualifications, abilities, interests. sammcd put it nicely: "What can you do for me?" You should have already answered this!

3) Your .info domain doesn't look very professional, and it doesn't point anywhere meaningful! That is, unless you're currently working for GoDaddy. Even then, the animated ads don't reflect well on you.

<comment><USER3> And yet, currently there's six people who've supplied emails for more contact.

<comment><USER4> A lot of people do a poor job at hiring too.

</comment></comment></comment><comment><USER5> I'm not really interested, but I think other people will have the same question I do, so I'll ask.

As a someone planning on launching a product very soon. What can you do for me?

<comment><AUTHOR> I can do any of the following: SEO, blogging, social network marketing, work to get you exposure on other blogs

</comment></comment><comment><USER6> I get the feeling that you are either vastly undervaluing yourself _or_ you don't have much to offer. Either is fine--but you should know which of the two applies best to you. You might still get an internship, but I'd argue if you give it some thought, you could get more bang for your buck(time and skills)!

1\. Pretend that due to a constraint, you cannot offer your services for free

2\. Ask yourself how much you can charge?

3\. You'll likely find yourself asking what you'll be charging for. Note down the answers because they are your _best_ skills.

4\. If you want to do it for free, think about what you'd like to gain in return. Consider it like swapping salary for a new skill or two.

This is a simple process to jot down what you can contribute, what your skills _may_ be worth, what you may be able to exchange your current skills for. As opposed to random crapshoot which will probably lead to a disappointing end-- as most things do if you're not somewhat clear about your goals.

Good luck! I saw your tumblr and you definitely have insights you can apply to all kinds of work.

</comment><comment><USER7> You can email me at firstname.lastname@example.com, if marketing online advertising technology (web analytics, split testing, etc.) interests you.

</comment><comment><USER8> I'd be interested in hearing more about what you're looking for, and offering. On gmail, I'm ebeland.

</comment><comment><USER9> shoot me an email if you'd like to chat about <http://ridewithgps.com> \- email@example.com

</comment><comment><USER10> Can you email me at firstname.lastname@example.com

</comment><comment><USER11> Please contact email@example.com

</comment><comment><USER12> email@example.com -- drop me a line and let's talk.

</comment><comment><USER13> shoot me an email - email@example.com

</comment><comment><USER14> Could you give me further info on gmail I'm pemotheodore? Thx

</comment><comment><USER15> send me an email at gmail (kapauldo), i'd love to talk.</comment>


Mapping Militants - <AUTHOR> http://mappingmilitants.stanford.edu/ <comment><AUTHOR> The Mapping Militants Project identifies patterns in the evolution of militant organizations in specified conflict theatres and provides interactive visual representations of these relationships. Relationships are traced in interactive maps, which provide visual representations of how those relationships change over time. The maps are also linked to profiles, which compile open-source news and data on militant organizations to provide a comprehensive, fully cited report on each group.

<comment><USER2> Who specified the conflict theatres?

What is a militant?</comment></comment>


Ask HN: What new skill do you want to learn in 2014? - <AUTHOR>

I want to learn Objective C and how to make iOS apps. How about HN? <comment><USER2> Regex. I have been aware of its existence for probably a year or so, and can generally recognize when it should be utilized, but I am far from being able to make the leap from a string-pattern-identifying algorithm in my brain straight to a regex. I usually have to - at that point - refer to a book or online resource.

</comment><comment><USER3> Front-end design. I can make a beautiful back-end, but what does it matter to anyone but fellow hackers if a front-end end-user thing doesn't look good, is useful to beginners, but is also useful to those who've been around the block a bit?

<comment><USER4> I actually have little experience in neither, but even so, my interest leans towards back-end design. Could you recommend any resources for teaching myself?

</comment></comment><comment><USER5> Enough mathematics to understand Andrew Wiles' proof of Fermat's Last Theorem. It's probably an unrealistic goal but I'm trying.

</comment><comment><USER4> Nimrod, German, efficient functional programming, algorithmic analysis & design, and analytic number theory

</comment><comment><USER6> I want to develop apps for FirefoxOS and UbuntuOS.

</comment><comment><USER7> Ruby on Rails and Obj-C/iOS

</comment><comment><USER8> Scheme and Pharo Smalltalk; Spanish.

</comment><comment><USER9> Go!</comment>


Object Oriented Design principles Java programmers should know - <AUTHOR> http://javarevisited.blogspot.com/2012/03/10-object-oriented-design-principles.html <comment><USER3> The author lacks conviction:

        "if you use a hardcoded value more than one time consider making it public final constant"

This should obviously be: "if you use a hardcoded value, make it a public final constant"

And:

        "if you have block of code in more than two place consider making it a separate method."

This should be: "if you have a block of code, consider making it a separate method"

Also, half of these principles imply the other ones.

edit: This is meant seriously btw, if you're giving advice to novice programmers, the instructions should be clear. If you say 'consider making a separate method' what should the programmer consider? If the programmer is new to this he or she won't know what considerations to make either.

This goes for all principles by the way, they're all fine and dandy but they're also trade offs. Every time you abstract something, you risk obfuscating the code for the uninitiated.

As arethuza suggests, Keep It Simple Stupid is also a solid design principle, and it contradicts a whole lot of the other principles.

<comment><USER4> I don't agree with "if you have a block of code, consider making it a separate method". I've seen it done and done it myself in the past, and it ended up being a whole lot of methods used only once and described well (by name). However it added unnecessary complexity which added to the cost of ownership of the classes. I hope someone can relate.

<comment><USER5> I can relate - it can also be a way where you can introduce meaning to your code. As opposed to a a series of instructions without clear intention, you can put them in a function that has a name that signals your intention. So you are labelling what that code does, using language features. I'm sure there are plenty of examples of this done well and done badly.

<comment><USER6> Not only meaning, but also separation. Two chunks of code after each other in a method can communicate via all kinds of mechanisms, e.g. having the same variable in scope. As a reader you will have to check for these communications to understand the method, even if those two blocks of code do not in fact communicate.

If you separate the block out into their own methods, they reader will have a much easier time verifying that they are decoupled.

</comment></comment></comment></comment><comment><USER7> Some of us working in hybrid OO-FP languages or strictly FP languages might argue against IoC. I have seen and been exposed to code bases while beautifully written are completely untraceable in cause-effect debugging. Which combination causes the error? Which config was that environment set to? Let me try to divine the structure...

<comment><USER8> I've always worked with OO, not FP. I dislike IoC for the same reasons. Also it's anti-KISS and debilitates encapsulation.

The worst effect of this kind of doing things is the image of programming that it shows to beginners. Programming well has nothing to do with that, really.

</comment></comment><comment><USER9> There is one other "principle" that I think all programmers should keep in mind: Programs typically exist to satisfy a user's need, not provide some intrinsic code value to you.

<comment><USER10> Which has absolutely nothing to do with OO specifically.

<comment><USER9> Agreed. But all too often I see people trying to adhere to some paradigms "principles," at the expense of the user value.

I mean, of course you shouldn't try and deliberately flaunt any good guidelines, but the measure of your code is ultimately not these.

<comment><USER10> I think that is implicit.

The guidelines set out here allow you to deliver that value without having to rip up your product for every minor change.

<comment><USER11> The problem I have with lists of 'principles' like this, is that they usually carry the presumption that there are no exceptions to any one of them. IMO this is not a good way to introduce novice programmers to sound software architecture, and often leads to an unmaintainable mess of 'flexible, extensible, loosely-coupled code' that does not 'repeat itself' and 'encapsulates and abstracts away implementation details'. Especially in situations where a) none of these things actually matter, or b) most (or all) of them could have been realized with much less complexity.

Just as an example, I really hate principles like 'program to interface, not implementation'. More often than not, you are not writing 'extensible frameworks' or 'reusable classes', so hiding each.and.every.class behind an interface serves no purpose. I get really depressed browsing the typical Java or C# code written by all the architecture astronauts around me that are obeying some variant of the '10 object oriented design principles' and thinking they need to make ISomething for every Something constructed by a AbstractSomethingFactory they can dream of, even though it's completely obvious only one kind Something will ever exist.

TL;DR: there's almost as much risk creating crappy code blindly following what is commonly sold as 'OO design principles' as there is in hacking up everything with complete disregard of sound design and architecture.

I think this should come pretty close to what your parent poster was trying to say. I also think many developers working in languages that aren't strictly OO would agree.

<comment><USER10> It's not about how many ISomething's exist - it's about defining a contract between Something and the rest of the system.

When it comes to testing, how are you going to test your ClassX if it's tightly coupled to ClassY rather than IClassY (which can be mocked/stubbed)? Oh, you have to test both.

Also, an interface is a great way of implementing "worry about that shit later - just let me talk to it now". You can define and evolve the contracts before you have to refactor expensive implementations.

As for AbstractSomethingFactory, I've not written a bit of code like that for night on 10 years. The container gives me what shit I need, ready configured with all dependencies.

Blindly following rules is dangerous, but burning entire books for what appears to be lack of experience is much more dangerous.

<comment><USER11> >> _It's not about how many ISomething's exist - it's about defining a contract between Something and the rest of the system._

Why would I need to introduce a separate interface class to define this contract, instead of making it explicit through the public class interface? What problem do I solve by adding another layer of abstraction between Something (the class) and Something (the interface), if Something is just some internally used entity that isn't part of a framework or public API? I've seen millions of lines of code to date, and the number of times hiding public class interfaces behind interface classes (note how those sound almost identical, wonder why that would be?) can be counted on the fingers of one hand. Interface classes only make sense if you expect classes to be used like you would use components in a component-based architecture, e.g. for plugins, or polymorphic, adaptable structures that may be implemented by combinations of classes, etc.

>> _When it comes to testing, how are you going to test your ClassX if it's tightly coupled to ClassY rather than IClassY (which can be mocked/stubbed)? Oh, you have to test both._

You don't always need interface classes for loose coupling, abstract base classes cover many cases, and in many other cases loose coupling is simply not required. There is nothing wrong in testing multiple classes that are tightly coupled together, without stubbing. In those cases where loose coupling is absolutely essential (frameworks for example) and you want to compose classes to provide some kind of interface, use interface classes. My point is not that interfaces classes are wrong, but they are overused, and more often than not, they add complexity without benefits.

>> _Also, an interface is a great way of implementing "worry about that shit later - just let me talk to it now". You can define and evolve the contracts before you have to refactor expensive implementations._

Again, I don't see why you would need interface classes for any of this. I can write a stub class that let's me 'worry about shit later' simply by defining its public interface and leaving its implementation empty. If I have a lot of classes adhering to the same (semi-) abstract interface and I don't want to stub them all with empty methods, I simply create a temporary base class I can remove later. Eventually I'll have to implement everything anyway, and I'm not writing interfaces just for the fun of it, or the remote possibility that some interface may be required later, even though no-one asked for it.

>> _As for AbstractSomethingFactory, I've not written a bit of code like that for night on 10 years. The container gives me what shit I need, ready configured with all dependencies._

Interesting that you should say that, because I used AbstractSomethingFactory simply as a caricature of an often overused design pattern, without implying that you should never write an abstract factory. In fact, abstract factories are a useful solution in many common designs, even though they are so overused.

>> _Blindly following rules is dangerous, but burning entire books for what appears to be lack of experience is much more dangerous._

Which means we have to aim somewhere in between, which is exactly what I was trying to say in the first place. Unfortunately many developers somehow seem to drift to either one of the extremes, the Java/C#-like language programmers to the 'create moar classes!' side, everyone else to the 'just make it work' side. My point is that both lead to unmaintainable, bug-ridden code.

<comment><USER10> Firstly the interface isn't a layer of abstraction - it's a contract, a boundary. An abstraction is an arbitrary concept which may or may not apply to an interface.

Secondly, the abstract base concept is actually a deadly form of coupling. As many people have suggested since the dawn of the problem, composition is better than inheritance and what sits at the composition boundaries? Interfaces! Inheritance usually turns into an LSP-violating [1] clusterfuck. I know - I have spent 2 weeks refactoring one into something which doesn't stick a fork in your eye every time you change something. And this is a non trivial one with over 100 classes in the inheritance graph (this is a roughly vomited out version of the Party archetype from the MDA book [2]).

So your tests are chock full of empty stub classes rather than mocks? Yuck.

If you look at ASP.Net's native API (before System.Web.Abstractions hid all the crimes away), you will see the sort of shit you'll get yourself into if you follow your own advice.

Agree with your last point though.

For reference, yes I am an architecture astronaut with one foot nailed to the ground :)

[1] <http://en.wikipedia.org/wiki/Liskov_substitution_principle>

[2] [http://www.amazon.com/Enterprise-Patterns-MDA-Building- Arche...](http://www.amazon.com/Enterprise-Patterns-MDA-Building- Archetype/dp/032111230X)

<comment><USER11> >> _Firstly the interface isn't a layer of abstraction - it's a contract, a boundary. An abstraction is an arbitrary concept which may or may not apply to an interface._

That's just semantics, let's concentrate on why I would always want to have an interface class instead of using the public class interface as the contract between a class and the rest of the system using it. Remember that _many_ classes in _any_ software design don't have (or need to have) base subclasses, composed classes, abstract interfaces, whatever. They are often nothing more than pieces of data with related methods, and nothing else. Writing lots of fluff around them to make such classes extensible, flexible, replaceable, loosely coupled, easy to stub for testing, whatever, does not add any value for you (as the programmer), your colleagues (when reading the code) or the customer (when running it). You'll know it when you'll need to do all of this anyway, and the moment you know it is early enough to think about it, no need to have contingency plans for things your classes are not ever going to be used for.

>> _Secondly, the abstract base concept is actually a deadly form of coupling. As many people have suggested since the dawn of the problem, composition is better than inheritance and what sits at the composition boundaries? Interfaces!_

Interfaces, not interface _classes_. We have many classes in our codebase that composite other classes, and none of them have interfaces at all, because the whole codebase is C++, which doesn't even have the concept of interface classes. Yet, our codebase is very clean and robust, fully covered by unit and integration tests, and rarely (if ever) contains bugs that are caused by bad or inflexible architecture. It does happen, on occasion, that some part of the code or its design doesn't satisfy new requirements anymore, but when that happens we simply refactor it, and if needed (which is extremely rare) write a facade around it to support its old public interface.

Note that I'm not saying I'm happy with the fact C++ doesn't have interface classes, because there definitely are situations I would want to use it, for example where a component-based design would best fit the problem at hand. In those cases we usually introduce a pure-abstract class that mimics an interface class, which isn't ideal but does the job.

I'm not sold on the 'abstract base class is a deadly form of coupling' at all. This may hold in some situations where you have many classes interacting in an architecture or framework that has a high probability of changing/evolving over time, but as I've said before: most code isn't like that. Most code is actually pretty plain and boring, without much need for architecture at all. Two or three levels in your class hierarchy and not more than a handful of class dependencies can solve a surprising amount of programming problems. Indiscriminately discarding inheritance or abstract base classes as 'evil' is naive at best, ignorant at worst. I can come up with many programming problems that are a perfect fit for concrete and/or polymorphic classes deriving from (semi-) abstract base classes, that would most definitely not be better implemented using composition.

>> _I have spent 2 weeks refactoring one into something which doesn't stick a fork in your eye every time you change something_

Similarly, I've spent a whole lot more than 2 weeks refactoring big balls of mud created by developers who threw as many classes against the wall as they could come up with, introducing interfaces, delegates, composites, strategy classes, and whatever other design pattern they found in the GoF book, only to arrive at the conclusion that 80% of the code was boilerplate, and the solution that was spread out over all those classes could be implemented by 1/10th the lines of code, concentrated in one or two classes. YMMV depending on the application domain you work in, but having worked on large business logic applications, web applications, and (now) scientific simulation software, my experience is that most complexity in software systems is only there because someone introduced it, not because it is necessary to solve the problem it was supposed to solve.

>> _So your tests are chock full of empty stub classes rather than mocks? Yuck._

Our test cases aren't full of stub classes, and they arent full of interface classes either. Most classes can be perfectly tested in isolation by simply instantiating them and feeding them with static inputs. Some others are tightly coupled and covered by integration tests. None of this is rocket science, we're at over 1M SLOC and we have no problems covering them in our tests.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> How is any of this specific to the mess of the language that is Java?

<comment><USER5> This is true, it's essentially a summary of some of Clean Code by Robert Martin. Principles applicable all over the place.

However to turn things a bit more constructive, let me know what languages you see as less of a mess if you have the time. It doesn't matter whether we agree and I'm not looking for a fight, just your opinion and reasoning. I might well agree.

</comment></comment><comment><USER13> Shouldn't KISS (Keep It Simple Stupid) be in that list?

Or at least avoiding "general-purpose tool-building factory factory" factories:

[http://discuss.joelonsoftware.com/default.asp?joel.3.219431....](http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12)

<comment><USER14> The list as a whole covers KISS. Every (including those not on the list) programming principle is aimed at the end goal of keeping things simple to prevent maintenance headache.

<comment><USER15> "Don't repeat yourself" competes with KISS. DRY creates brittle code.

There's low harm in duplication of code. When something changes you don't have to refactor your class structures. You just change the code for the thing it affects. And if you have to make multiple edits it's often pretty obvious what you need to do.

(Data and configuration are different, it's more important for these to have a canonical home.)

<comment><USER14> I strongly disagree. DRY does KISS. Much easier to maintain one instance of a function/method/block of code than multiple copy/pastes. If something requires different behaviour to what is in that extracted piece of code, then it shouldn't be using the piece of code at all. Therefore KISS and remove that reference. In conjunction with the other principles - delegate and DI/Inversion in particular - it'll be easy to substitute the delegate and minimise change.

<comment><USER16> To me, that describes "maintainability", not "simplicity".

<comment><USER13> Over the years I've seen a _lot_ of disagreement between developers as to what "simple" means.

<comment><USER16> Yes, and some definitions are wrong ;)

I invoke Layne's Law and go back to work.

<comment><USER13> Perhaps the best example here being whether SOAP is simple or not - <USER2> people think it is, others disagree....

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I don't agree with most sentences on programming that contains the words "prevent someone from".

"Classes, methods or functions should be Open for extension (new functionality) and Closed for modification. This is another beautiful object oriented design principle which prevents some-one from changing already tried and tested code."

No, no, no. Let someone modify whatever the hell they want. If they screw it up, that's on them. Quit it with this childish belief that you have to control people.

<comment><USER3> Yes, but I think the closed principle is more about providing an interface, i.e.: the interface should be closed for modification so that implementing classes or interfacing services do not have to be changed everytime you add a feature.

My girlfriend came up with a nice metaphor trying to follow along. The open/closed principle applies to natural language as an interface. It is important language can be extended to convey new meaning, but also important that it is closed for modification so we retain the ability to understand eachother.

<comment><USER17> With the exception of service APIs in which everyone is forced to use the latest version, I still don't agree. If we're talking about libraries, nobody is forcing people using the library to upgrade to the latest version (or at least shouldn't be). If you have a good reason to change the interface, change it, don't let the fact that it doesn't match previous versions of the interface prevent you from improving the product.

</comment></comment></comment><comment><USER18> Regarding rule "Object oriented design principle 8 – Interface Segregation principle (ISP)" ... I think this is often overused. I only introduce interfaces when there is more than one implementation. Of course if I'm designing stable API this is different.

Also see: <http://stackoverflow.com/a/90915/343699>

<comment><USER19> It can, especially to novice developers, be very helpful to be forced to think of a class exclusively in terms of it's interface. Bad design seems to stand out more.

<comment> qu4z-2 I would agree. Depending on implementation details tends to lead to much tighter coupling between components.

</comment></comment></comment><comment><USER20> This is worded really quite badly, but makes a good set of points.

</comment><comment><USER21> One thing that was conspicuous for its absence was the "Law of Demeter." Is this not considered a good practice any more?

It's trickier to use, because blindly applying it can lead to immense classes, but I find it a useful thing to keep in mind.

<comment><USER22> The rails delegate helper really helps with this, just declare which methods you want forward, optionally with a prefix. Sometimes a different name is more descriptive but this covers a large portion of the cases.

        class Foo < ActiveRecord::Base
          belongs_to :greeter
          delegate :hello, :to => :greeter
        end

</comment></comment><comment><USER23> .equals ()? really? why not just ==?

</comment><comment><USER24> Oh the memories. It's not very well written but most advices are sound if you're stuck in that very particular Java / C# hell.

The book _"Effective Java"_ (from 2001) still has to one the "must read" for any Java programmer that didn't read it.

In it Joshua Bloch has always been very clear, from the start, about all the deeply ingrained ugly Java warts that Java had from the start (and still has). Like for example the complete and total utter impossibility to respect the equals() and hashcode() contracts in the face of inheritance.

Took a long time to set in but now quite some Java programmers are beginning to accept that having equals() and hashcode() at the top of an inheritable OO hierarchy may not have been the greatest thing since sliced bread.

The second book to read is Goets and al.'s "Java Concurrency in Practice" (one of the best looking programming book cover ever, which never hurts an incredibly high-quality content).

But the real lesson is that: Java is too complicated and has way too many warts to ever produce beautiful code. The JVM is not all bad but "Java the language" is really fugly.

Switch to a language that has a saner way to deal with concurrency (Say Clojure's STM or Go) and you can throw most of the pages in these books to the trash.

<comment><USER25> Can you go a little more into the problems with equals() and hashCode(), or link to something? I'm by no means a hardcore Java programmer, but I've used it for several projects, and these never stood out as particularly problematic to use and override, although I kind of see how they come across as kludgy in a whitetower kind of way.</comment></comment>


Live code reloading for Golang web projects on Makefile in 19 lines of code - <AUTHOR> https://medium.com/@olebedev/live-code-reloading-for-golang-web-projects-in-19-lines-8b2e8777b1ea

<comment><AUTHOR> In this article I would like to show how you can organize your golang web project with live code reloading. It scheme can be easily extended and will allowed to write couple of line in bash to get what you want.</comment>


Ron Paul says his campaign is more than "a few spammers" - <AUTHOR> http://www.nytimes.com/2007/11/11/us/politics/11paul.html?_r=2&hp&oref=slogin&oref=slogin

<comment><USER2> Oh no, please don't let Hacker News turn into Ron Paul News... I mean Reddit.

<comment><USER3> Seconded. I predict this will degenerate into a flame war. I hate censorship but I doubt if we need political posts on YC news.

</comment></comment><comment><USER4> I think you took a wrong turn on your way to <http://politics.reddit.com>

</comment><comment><USER5> This is a really hard thing to bring up. I want to sugarcoat this as much as possible, because I'm running the risk of flamebait. Maybe it's better we don't think about this, but as a community perhaps it's something we have to face. I don't know, but for better or worse here it goes...

Does a user voting this up become smarter or dumber in the eyes of the algorithm?

What does the answer to this question mean?

<comment><AUTHOR> I have the impression that Paul Graham hasn't implemented that algorithm yet and/or turned it on because the community hasn't yet degenerated enough. I can't find the specific post where he said that.

<comment><USER6> That's true. On the other hand, when I do turn it on, it will apply retroactively.

As for the question of what effect this story has, that depends on what the editors think. Probably they'd be split on it. This is arguably an Internet story as much as a political one.

</comment></comment></comment><comment><USER7> Why did you post this here rms?

<comment><AUTHOR> Ron Paul responded to Paul Graham's claim that Ron Paul will only be remembered for gaming social news sites.

<http://news.ycombinator.com/item?id=76477>

<comment><USER7> That's a little disingenuous. All the article contained was one paraphrased quote on his campaign being more than a few spammers. It certainly has nothing to say about the voting patterns of ron paul devotees on reddit.

For the record I think the ron paul movement on reddit has in no way been consciously controlled. I think its a classic case of internet mob syndrome. Its like the way people follow the righteous indignation of someone whose camera has been stolen, people band together to right the wrongs against ron paul. Its still a failing of the voting system of reddit though, because ron paul articles just aren't interesting to those not caught up in the mob.

</comment></comment></comment><comment><USER8> Sure that open quote wasn't two words to the left?

<comment><USER9> i was about to say that!

the campaign need stickers like "I spammed 1000 message boards for Ron Paul, 08"

<comment><USER9> to whoever downvoted my comment... you really know how to make friends and influence people!

the funny thing is, i might even vote for ron paul, i just think ron paul supporters need to analyze their own behavior a little more carefully</comment></comment></comment>


Apple's 'Behind the Mac' ads have a double meaning - <AUTHOR> https://www.theverge.com/2018/6/15/17467232/behind-the-mac-behind-the-competition <comment><USER2> Honest question... how is this happening? Apple has 123 thousand employees (assuming whatever I just read is correct) and has the largest market cap of any publicly traded company. They're sitting on way over $200 billion. I would think they have the people and the money to make everything AMAZING, but so much of what they are putting out now seems... I dunno, just meh.

What are all those people working on? I don't think it's fair to expect them to reinvent and innovate the heck out of everything all the time, but after reading this I can't help but think "what are they doing?".

They have SO SO MUCH. So many people, so much money, so much everything, but... I dunno, from where I sit I don't see much interesting coming out.

I could be wrong, maybe I'm missing some things they're doing. I don't mean to say they're not doing anything, but with all they have, it seems like they could be doing so much more. Or am I wrong?

<comment><USER3> > I don't think it's fair to expect them to reinvent and innovate the heck out > of everything all the time

I think the problem is that Apple themselves want to reinvent and innovate the heck out of everything all the time, so they're making it harder than it needs to be. New Mac Mini? Easy: spec bump the current form factor. New Mac Pro? Easy: put the latest and greatest CPU/GPU in the old cheese-grater enclosure. But no, Apple needs to contantly make everything smaller/thinner/lighter/quieter, so they redesign the enclosure and reengineer the internals from scratch. While they're busy doing this, they continue to sell the old unimproved products for years.

Yes, Apple, we know you can innovate. But you say that for every "yes" there are a thousand "nos". Have you considered saying "no" to a complete reinvention of your hardware when your current offerings are so out-of-date? Your customers would be happy with a spec bump of the current form factors.

<comment><USER4> > _I think the problem is that Apple themselves want to reinvent and innovate > the heck out of everything all the time, so they 're making it harder than > it needs to be._

This right here is what I believe to be the central problem with the Mac's strategy since about 2013. Somehow, "can't innovate" became this thorn in the side for Apple management, this black eye that they felt they had to come back from, to prove everyone wrong. No moment better expresses this than Phil Schiller's infamous "can't innovate, my ass" ad-lib on the 2013 Mac Pro unveiling.

And so what we have now is a pendulum that has swung entirely in the opposite direction, arguably further than it ever was on the supposed "can't innovate" side: Every Mac launch must be "innovative." Every new Mac must showcase new design and technologies or break new ground, and products that can't support this level of engineering investment (like the Mac Mini) get left behind.

In other words, the entire Mac business unit has transformed into a vanity project. My dream would be for "vanity project" to become the new "can't innovate" - a challenge that spurs Apple to action in correcting course on its oldest product line.

And perhaps some day, Schiller will take the stage to announce a boring, but pragmatic new line of workhorse Macs, and mutter "vanity project, my ass."

</comment></comment></comment><comment><USER5> Kind of a rip off of this blog post[0] from Rogue Amoeba, down to the same screenshot and everything.

[https://weblog.rogueamoeba.com/2018/06/14/on-the-sad- state-o...](https://weblog.rogueamoeba.com/2018/06/14/on-the-sad-state-of- macintosh-hardware/)

<comment><USER6> Extensive HN discussion about the original blog post here:

[https://news.ycombinator.com/item?id=17312588](https://news.ycombinator.com/item?id=17312588)

</comment></comment><comment><USER7> It's fine to criticize the Mac, but using the marketing phrase to do so makes no sense except to say it's false. If it had a double meaning that would mean other computers were... behind the Mac. How would a double-meaning on the phrase make it sound like the Mac was behind other computers?

</comment><comment><USER8> I've been a mac user for a long, long time... but their approach to their hardware offerings has been abysmal over the past couple of years.

The pivot from being the tool of choice for professionals to being the word processor and social media browsing terminal for ignorantly enthusiastic consumerists has been unappealing to say the least.

A home build with Linux and the new OnePlus 6 is starting to look like a very attractive alternative at this point.

<comment><USER9> Why do you have to put people down who aren't professionals and who consume media as 'ignorant'?

Not requiring a high-spec machine makes you 'ignorant'?

<comment><USER10> $2000 for a machine used only for Netflix streaming, Facebook, and basic web browsing, is pretty ignorant.

<comment><USER9> It's not ignorant, it's just a choice you personally wouldn't make. Maybe people value the design of the device rather than the tech specs? Who knows?

</comment></comment></comment></comment><comment><USER11> Why is Apple still selling any of this stuff?

Presumably people are either: a) still buying these devices, or b) they aren't

Either case can be used as a reason not to bother updating them.

I'm running a 2012 AMD rig at work with GTX 650 Ti and four displays, and at home a late 2012 Core i5 MacBook Pro Retina, and I don't feel compelled for technical reasons to upgrade to anything faster.

It's not like a new Mac or PC will play streaming movies any better. I'm actually glad to see the end of needing to upgrade every few months.

<comment><USER12> In my company IT upgrades the laptops. Most people hate it, but IT doesn't care. This is the reason apple is still selling that crap. Apple is running on Inertia. Pretty soon people will move to other alternatives.

<comment><USER13> Apple becoming the thing they rallied against in the early 2000s is a sad state for the company despite its earnings. But investors are aware that they need to get ahead on something to keep that going at least.

When Microsoft's Surface series looks really attractive to me after 15 years of OS X and Mac investment, I'm not sure if Apple really can pull ahead without a massive game changer. Incremental changes so far are pointing to IOS application-ification of the entire Mac ecosystem.

</comment></comment></comment><comment><USER14> I got one of these new MacBooks at my new job (I requested a PC so I could run Linux, but they had already ordered a Mac) and I think I lasted on macOS for two days before I installed Linux. It was a pain to get working, but I'm really glad I did:

[https://penguindreams.org/blog/linux-on-a-macbook- pro-14-3/](https://penguindreams.org/blog/linux-on-a-macbook-pro-14-3/)

I haven't been a fan of osx since Snow Leopard, back before they destroyed Expose and replaced it with that Mission Control rubbish and completely mutilated Final Cut Pro.

</comment><comment><USER15> I've always stated that Macs are a User's machine, not a Pro machine. And no number of "Pros" on stickered macs in conferences will convince me otherwise. The thing with a User's centric machine is that there are WAY more users than pros. Pro is a niche market. A sizeable one, but still niche compared to User space.

</comment><comment><USER16> I honestly think everyone is missing some cues Apple has been sending.

They're building their own chip for desktops. Wait... let me hypothesize and break it down for you one time.

One, the recent privacy concerns and backdoor built in for AMD and Intel chips. They riding that we care about your data train.

Two, their homegrown Axx chip is in all new mobile devices. Whats to stop them from making a bigger one or use the same one for desktops? Probably why the new Mac Pro has been delayed as well as other device refreshes. And letting the profit of the under spec'd overpriced Imac Pro fund them in the mean time.

Three, their recent poaching of Intel employees and hiring of linux devs too. I would assume for low level engineering. Maybe even integrated graphics too?

Four, Macs originally used to have their own custom ARM chip, so Apple has a history of being self contained. One of the adages to tech is build, partner, buy. You usually do one until you can do one of the others.

I suspect you will see them release a new desktop(s), running their newly made chip, possibly with integrated graphics like they do now for the mobile devices. Some abilities to upgrade, so they can get you on the over priced upgrades and accessories. Like RAM, HDD, and maybe, just maybe CPU. That last one I am on the fringe with, I know.

Again this is just my observation, and hopefully I can look back on this post some day and either laugh or be like I told ya'll so.

Thanks for reading this post.

</comment><comment><USER17> The real message is exactly the opposite of what the article supposes. The real message, now directly from Apple, is "fuck you, our old ass shit is good enough for you cause we say so." This is obvious because they are spending money on marketing rather than on actual products. Probably, they aren't planning on releasing anything new this year nor fixing their egregious issues with both hardware and software. Why would they when most people are perfectly happy to give them money for inferior, outdated, and recently garbage products? Apple doesn't care about customers, they care about numbers and the numbers are telling them there is no market for laptops and desktops anymore. Too bad there's more to running a business than numbers and I suspect Apple is about to find that out the hard way over the next decade. From the brink of bankruptcy to the brink of bankruptcy would not surprise me at this point given their horrific product offerings these last three years, including ios and iphones.

</comment><comment><USER18> I bought the late 2016 mbp on a whim (the price in Japan was just too good to ignore) but I'm so disappointed. The keyboard is trash, I dread every time I have to work without an external one. I barely ever use that keyboard, and yet after 14 months the "b" key is somehow faulty. I had to start putting all dongles in checked-out baggage because airport security now thinks I'm carrying bombs -- nobody would have that many short cables in a carry-on! The enlarged trackpad is almost comical, without actually helping anything; and the touchbar is just another set of lights I never look at.

I'm now worried I'll never be able to flog this for even 20% of what I paid, and I'm so tempted to switch to a prebuilt Linux laptop -- there are a few options with chassis that look a lot like the 2015 MBPr...

The feeling of complete technological triumph that I got from the previous MBPr model (5 years of service, barely a scratch) has fully evaporated, and no amount of propaganda will change that.

<comment><USER16> I am glad I am not alone in feeling like this. I too have a mbp, and somehow, Apple has lost the magic that once captured me. Even adding apple care, now has to be when you buy the device. Its no longer, one year, plus at the end of the year, add some apple care to extend it for a total of 3 years.

I have been leaning towards some of the same ideas and laptops. You may want to check out System76 if you haven't already.

</comment></comment><comment><USER19> Should be re-titled "Behind ON the Mac" to fit better.

I use my early 2015 MacBook Pro for some heavy work, I would love to upgrade soon but TBH I'm looking more at Thinkpads than Apple products right now...

<comment><USER12> me too... current dell and thinkpads are very good specwise and lookwise, even the touch pad is pretty good. if they sell Linux laptops I will get it the next day.

<comment><USER20> Thinkpads are Linux certified, I've installed Ubuntu on everything from ancient models to a just-released X1 Yoga and in my experience all the important things (excluding, say, fingerprint reader) "just work" out of the box.

</comment></comment></comment><comment><USER21> It's not hard to do spec upgrades. They do it for their iPhones. They can certainly do it for their desktop/laptop computers. As a developer, I really like my late 2016 MBP. However, I think it's absurd that I can walk into the store a few years later and purchase the exact same computer.

Seriously Apple, no one expects innovation every year on the desktop. But for christ sake, update the CPU and increase the RAM since you soldered it on a few years ago.

</comment><comment><USER22> It takes a lot of guts to use an early Daniel Johnston song in a national ad campaign.

<comment><USER23> It does. And it's one of my favorites. But I really don't know what Apple is trying to say. It's not a song that fills me with positive feelings.

</comment></comment><comment><USER24> I honestly think having a operations guy in charge is worse than having marketing in charge. At least marketing listens to the customers. Apple needs another product person who cares about quality of the Apple experience and not maximizing profit margin in the supply chain by producing older models or making questionable quality affecting decisions.

</comment><comment><USER25> I'm pretty over maintaining Linux on my laptop, Windows 10 in general, and most hardware coming from the "PC" side of the market. I'm also looking to get into iOS development.

What do I buy? I'm thinking the cheapest Air. I don't want to drop twice that for something that seems so reviled that they must update it soon. But can I do iOS dev on an Air? Are refurbed previous gen MBPs good quality for the price?

Do I wait till September and cross my fingers for an improved next gen that isn't $200 more expensive?

<comment> martin-adams 2 years ago I got a 2013 model Macbook Air with 512GB SSD / 8GB RAM for app development. Turns out I now use it as my daily driver and I had preordered the original Surface Book. Being a Windows user something made me switch (first Mac with an SSD and an ultrawide monitor).

I basically leave it docked all the time. I really want to upgrade because I need more RAM and for video editing. But to give you an idea, I'm using it perfectly fine with XCode running docker containers with Mongo/Neo4j etc. Email, web and office stuff is no issue at all.

I paid about £940 ($1200) in Jan 2016. After all this time, I can sell it for £300 (30% of it's original value).

<comment><USER25> Ah that's pretty encouraging. I see an $809 model right now from 2015 with 8GB/128GB which is all I need for my current day-to-day.

I'm not even sure how iOS development works yet, but you think the <2 GHz processor is fine with the whole toolset? Any complaints at all? Like any CPU intensive aspects that get bogged down

<comment> martin-adams The CPU is ok, not brilliant but works. I agree with the sibling comment that the 128GB will be a squeeze. For me RAM and storage (SSD) are most important.

I've also used VirtualBox a lot on this little thing and played in the iOS simulator (mainly to reproduce web bugs).

</comment></comment></comment></comment><comment><USER26> Minor nit: In case anyone was confused as I was, "lose the plot" is a British idiom [0]. It means, "To lose sight of an important objective or principle; to act contrarily to one's own interests through concentrating on relatively unimportant matters."

[0]: [https://en.wiktionary.org/wiki/lose_the_plot](https://en.wiktionary.org/wiki/lose_the_plot)

</comment><comment><USER27> Seeing a post about the decline of the Apple product line is like a daily ritual on this site now.

When the gap between products was short the Apple secrecy could be fun and exciting. That is no longer the case. Now I just feel like they have contempt for me.

</comment><comment><USER28> This is an embarrassingly empty article. They used the word "behind" in an ad... so here's a bulleted list of things people complain about regarding their products?

</comment><comment><USER29> They should be using their insane amounts of cash and market power to completely re-invent personal computing.

</comment><comment><USER30> It's better than the Apple ad about "facilitated communication" \-- a completely discredited way of getting non-verbal people to "talk" with what is essentially a Ouija board. _That_ was the most distasteful Apple ad ever.

</comment><comment><USER31> That voice over on the video was pretty annoying.</comment>


Why I quit Facebook and we are sharing much more than you think - <AUTHOR> https://www.linkedin.com/today/post/article/20140709173931-11228988-why-i-quit-facebook-and-we-are-sharing-much-more-than-you-think?trk=tod-home-art-list-large_0

<comment><USER2> Some good points but then posting it on LinkedIn? They are known to use scummy business tactics--you don't have to wonder what their "hackers" on staff are doing.

The irony almost made me unable to read the article.</comment>


The Anatomy of a Great Email Introduction - <AUTHOR> http://www.jasonshen.com/2011/the-anatomy-of-a-great-email-introduction/

<comment><USER2> here is how I do it:

firstly ask both parties individually if it is okay to intro, explain why the intro is requested. There is nothing worse than intros you do not want nor need. It makes all parties look lame.

The nice thing of asking both parties individually is that email is a great platform to say "no" - you simply ignore the first and follow up email, and the other sender gets the message - unless they truly believe it to be valuable in which case they'll try to reach you in another way, and if they do not know any other method to contact you than email, perhaps you need to become better contacts with the person before introducing them to other people ...

assuming all parties are game:

then send an email to both parties (both in To: field) with subject of <name1> (name1startup) <-> <name2> (name2startup) intro

then format email as such:

<name1>, <name2> is a blah blah blah ["good guy"] and is dying to chat with you about ["topic"]

<name2>, as recommended, <name1> is a blah blah blah ["smart guy"] and knows tons about ["topic"]

then sign off with a line along the lines of "hope this intro helps, and i'm sure i'll talk to you guys soon! plc"

and then when a party replies, they should _move you to BCC_ so that you know that the parties actually responded, and its a good way to prevent you from getting a ton of irrelevant to you replies. [the receiver typically starts with a line along lines of ["thanks for intro Peter! moved to BCC"]

(I do this with everyone, but I have had good friends intro me to people with only asking the other party - I think that is generally okay if you really know the person)

<comment><USER3> I definitely support the "email each party separately first", although usually the request for an intro comes during a conversation with one of the parties.

I also would dislike getting emails as long as the example from the article, but might want a tiny bit more info than your example. Maybe 2 sentences per person, focusing on how you know/why you vouch for credentials, and the ask.

Putting relevant searchable keywords in the subject line is key, too.</comment></comment>