WatchKit - <AUTHOR> https://developer.apple.com/watchkit/ <comment><USER2> There are actually 4 different types of Apple Watch apps:

1\. Glances

2\. Actionable notifications

3\. Extension WatchKit apps (extension runs on iPhone, view runs on watch)

4\. Fully native apps

It appears 1, 2, and 3 will be available for the initial launch, while #4 will be available later next year, probably starting with a beta released at WWDC.

<comment><USER3> hey orand, thanks for the summary.

You mentioned #4 will be available later next year, probably starting with a beta released at WWDC.

Is Apple actually saying this? If so, can you please share the source? I mean from Apple not macrumors.

<comment><USER2> They actually said this in their September 9th press release, although most people missed it:

[http://www.apple.com/pr/library/2014/09/09Apple-Unveils- Appl...](http://www.apple.com/pr/library/2014/09/09Apple-Unveils-Apple-Watch- Apples-Most-Personal-Device-Ever.html)

"With Apple Watch, developers can create WatchKit apps with actionable notifications and Glances that provide timely information. Starting later next year, developers will be able to create fully native apps for Apple Watch."

Someone from Apple also essentially reconfirmed this earlier today on the WatchKit developer forum.

Edit: here's the source that first tipped me off to this detail hidden away in the press release:

[http://david-smith.org/blog/2014/11/06/expectations-for- watc...](http://david-smith.org/blog/2014/11/06/expectations-for-watchkit/)

<comment><USER3> Appreciate orand.

I wonder what fully app for watch means though. I am intrigued on the touch event support. There is something new called Force Touch.

<comment><USER4> Apple mentioned Force Touch during the unveiling demo, and there is a blurb in their documentation as well:

 _" Force Touch. A small screen can only accommodate so many controls. That's why Apple Watch introduces an entirely new interaction model: Force Touch. As well as sensing touch, the Retina display also senses force. Force Touch interactions display the context menu (if any) associated with the current screen. Apps use this menu to display actions relevant to the current content."_ [1]

I've heard people compare this to a long press, but its subtlety different. Force touch can bring up a context menu faster, because you don't have to wait to determine if a touch is "long" or not

[1]- [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/WatchHumanInterfaceGuidelines/WatchOSAppAnatomy.html)

<comment><USER3> Thanks for the info Billy.

I think there has to be more touch events available than Force Touch. Seems a fairly trivial interaction.

Given the features page I assume the API should support more events. Digital Touch "implies" touch down-move-up:

[http://www.apple.com/watch/features/](http://www.apple.com/watch/features/)

* Section 6-left, a heart drawn on the watch with the name Jamie.

"You don't even have to use words. The Digital Touch features on Apple Watch give you fun, spontaneous ways to connect with other Apple Watch wearers, wrist to wrist."

* Below, a flower drawn on the watch with the name Eliza.

"Sketch. Use your finger to draw something quickly. Your friend on the other end can watch your drawing animate, then respond with a custom creation for you."

Hopefully is already there or else we might have to wait and see the touch API public for WWDC. Eager to play with it, if anybody has more information please share. Thanks!

</comment></comment></comment></comment></comment></comment><comment><USER5> Particularly interesting are the Human Interface Guidelines for Apple Watch: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/WatchHumanInterfaceGuidelines/index.html)

They feature various previously unknown details about the watch, for example that the two sizes have different display resolutions, 340px and 390px respectively.

<comment><USER6> It's particularly interesting to see which UI elements has made it to the small screen of the apple watch. Not much else than switches, buttons and sliders are featured in the guidelines. Looking forward to see what developers eventually will come up with for these devices.

</comment></comment><comment><USER7> Am I groking this right? The Watchkit app actually runs on the iPhone as an extension, and just the UI component runs on the watch hardware?

Edit: better direct link: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/WatchKitProgrammingGuide/DesigningaWatchKitApp.html#//apple_ref/doc/uid/TP40014969-CH3-SW1)

"The Watch app resides on the user's Apple Watch and contains only storyboard and resource files; it does not contain any code. The WatchKit extension resides on the user's iPhone (inside your containing iOS app) and contains the code and resource files for managing your Watch app's interface."

<comment><USER8> So if the phone is dead the watch won't even show the time?

Does this setup significant improve battery performance?

<comment><USER7> It looks like there are native Apple apps on the watch: they noted in the intro video that clicking on an image of a map opens up the Apple Watch's "Maps App"

<comment><USER9> You can add a map to your own app as well

<comment><USER10> You can add a non-interactive snapshot of a map.

</comment></comment></comment></comment></comment><comment><USER11> An interesting tidbit from the HIG ([https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/WatchHumanInterfaceGuidelines/Animation.html#//apple_ref/doc/uid/TP40014992-CH7-SW1)):

 _Create prerendered animations using a sequence of static images. Store canned animations in your Watch app bundle so that they can be presented quickly to the user. Canned animations also let you deliver high frame rates and smoother animations. Creating animations dynamically from your WatchKit extension and transferring them to Apple Watch adds a delay before playback can begin._

This is not a good sign as to the power of the watch, unless I'm drastically misinterpreting things.

<comment><USER12> The main problem is the battery life. All this seems to indicate that the device is deisgned to maximize it. A matter of trade-offs, really.

<comment><USER13> I also found this interesting: "(Dates & Timers) ... Does not need to be updated by your WatchKit extension". Makes me think of timer coalescing in OSX. Now they're just sidestepping the whole issue altogether.

<comment><USER14> Not necessarily timer coalescing and probably more of a radio optimization. All 3rd party code will run on the phone and not the watch, so any updates to the UI made via code will have to necessarily travel over Bluetooth.

Apple wants to limit the frequency of these updates, so the most frequently updated UI bits (clocks, timers) will be done on the device itself without the persistent BT use.

</comment></comment></comment></comment><comment><USER15> I would buy this watch, but I'm completely convinced that Android Wear is more spot-on for the watch UX with their card based user interface. It does have all these features, the glaces, the actionable notification, extension apps, but from UI standpoint it is just a card. Also, the UI on Android Wear is prettier. I'm not sure why Apple is using black ugly buttons that remind me on very first Nokia multimedia color phones.

<comment><USER16> I don't get the watch-craze at all, as it adds 0 things you couldn't do before. However, i m looking forward to Android Auto, something that i wanted for a long time.

<comment><USER17> > as it adds 0 things you couldn't do before

That's your opinion. For me it has been life-changing.

<comment><USER18> Would you mind elaborating on this? I'm in the same boat as return0 -- I just can't imagine what utility I'd get out of a touchscreen on my wrist.

<comment><USER19> Personally, I really enjoy the automatic sleep/activity tracking that my Pebble provides (via Misfit app)

Besides that, I mainly use it for "watch" stuff.

That said, it is really nice to be able to get notifications without taking my phone out in certain contexts—bicycling, walking, in a pool, phone charging in other room, etc.

</comment></comment></comment></comment></comment><comment><USER20> There's a lot of groaning about the constraints of the platform (battery life, available interface components, etc), but I for one am excited by these constraints. It can be a really fun and interesting challenge to design within constraints, and in this respect the watch reminds me of the early days of mobile computing. Those tiny little battery-limited devices forced one to think differently about what a UI is, compared to the gargantuan desktop computers and their nearly cinematic display resolution.

<comment><USER21> > It can be a really fun and interesting challenge to design within > constraints

It'll be fun as a technical exercise and to satisfy one's intellectual curiosity, but not as much fun once you've identified the workarounds for all the constraints and you're just trying to ship.

</comment></comment><comment><USER22> Based on the typography guidelines, the DIN-like font used on the Apple Watch is named "San Francisco": [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/UserExperience/Conceptual/WatchHumanInterfaceGuidelines/ColorandTypography.html#//apple_ref/doc/uid/TP40014992-CH9-SW1)

Here's hoping it will replace Helvetica on iDevices and Macs as well...

<comment><USER23> San Francisco? That font is over 30 years old ([http://en.m.wikipedia.org/wiki/San_Francisco_(typeface)](http://en.m.wikipedia.org/wiki/San_Francisco_\(typeface\)))

<comment><USER24> If only they had gone with the "classic" San Francisco font you linked -- the Watch's whimsical level would be off the charts!

<comment><USER25> It's a graphical illustration of the San Francisco of Armistead Maupin vs. that of Jony Ive.

</comment></comment></comment></comment><comment><USER26> A quick scan makes it look like you don't have direct access to create your own UI elements, you are stuck to the prebuilt stuff.

This definitely is designed to maximize battery life

<comment><USER7> Yeah, and you can't create UX elements on the fly, they have to be contained in the bundle pushed to the phone. So, less to install/push/change over the phone/watch network connection.

</comment></comment><comment><USER27> Following that link consistently makes my Firefox crash. Anybody else experiencing this?

<comment><USER28> Crashing firefox here too. I had it crashing multiple times until I realized it was this tab that was causing it.

</comment></comment><comment><USER29> I think they've gone about this the wrong way, architecturally. I would have streamed draw commands to the watch and received touch events back, with the watch hardware essentially being a display client with no compute power of it's own. That would cut silicon real estate, remove the need for local wifi, etc - and placed the development focus on a super low latency wireless command stream. That way, the watch, as a product, would last much longer between upgrades, and your UI complexity would be bound by the host phone, not the little SoC.

<comment><USER30> See wiremine's post here:

"The Watch app resides on the user's Apple Watch and contains only storyboard and resource files; it does not contain any code. "

<comment><USER29> With regards to the WatchKit apps - I'm sure I read they were static resources - essentially a GUI library that can run on the watch. That's subtly different to being able to render any command in a draw stream, say, from CoreAnimation. The former gives a storyboarded GUI from a resource set (sliders, buttons, etc), with static animated images (!), the latter is more flexible and I think would be less resource intensive watch-side (render display commands vs local GUI library)

If you wanted to go super-minimal, you could even probably stream a compressed bitmap to a screen that resolution over a wireless protocol, moving all rendering phone-side.

There's also still the issue of the native watch apps coming in 2015.

</comment></comment></comment><comment> k-mcgrady Yay! This will keep me busy next weekend I'm sure. Quickly glanced through the catalog of objects available and it doesn't seem to be borrowing UI from iPhone the way iPad did. Some similar UI elements but judging by the names they are different implementations and not just differently scaled/laid out.

</comment><comment><USER31> Do you think we will be able to build custom watch faces at some point?

<comment><USER32> Doesn't look like there is any support for drawing on the fly. You could create the watch face as static image, but I don't see a way of drawing the hands and keeping them moving once a minute. Maybe create a series of static images with the hands, and stream them once a minute from the phone? Anybody have any thoughts?

<comment><USER19> Seems like this is the type of thing that might be possible once the "fully native watch app" sdk is released.

</comment></comment></comment><comment><USER33> Anyone have a link to available APIs?

<comment><USER34> you can start here, but you might need to be a registered dev to get to the content:

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/WatchKitProgrammingGuide/index.html)

<comment><USER33> Thanks! I am a dev, but was mainly curious if they were opening up the heart rate sensor to apps directly or if we would have to go through HealthKit.

<comment><USER35> It looks like mostly interface related things, for now. [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/WatchKit/Reference/WatchKit_framework/index.html)

</comment></comment></comment></comment><comment><USER36> Are they allowing access to the sensor data from the watch? I'm particularly interested in heart rate.

A brief scan of the documentation didn't show anything obvious.

<comment><USER13> Nope. Check the dev forums @ Apple.

</comment></comment><comment><USER37> You can cache images on the watch using WKInterfaceDevice.currentDevice() but there is no way to check if an image has been cached, lol.

Can store up to 20 mb.

</comment><comment><USER38> Also [https://news.ycombinator.com/item?id=8625526](https://news.ycombinator.com/item?id=8625526).

</comment><comment><USER39> Looked like there were a lot of motion detectors on the Apple Watch. Any guesses on whether they'll expose that in the SDK soon?

</comment><comment><USER40> I'm happy to see new products and a competitive landscape but frustrated to see Apple (and others) using different development processes. It's already painful to write apps that work on all 3 major mobile OSes, but now watch app developers have a huge set of watches they need to develop for too.

Frustratating to see products each trying to compete using their own closed ecosystem, because it hurts developers and it hurts innovation.

<comment><USER41> I understand your frustration, but I don't think products trying to compete with closed ecosystems hurts innovation. The smartphone race ushered a new era for software development. The new development process made it mandatory (in order to stay competitive) to reconsider your software for the specific hardware, which promoted some very good redesigns and innovation that would not have happened otherwise.</comment></comment>


Building a Simple Swift App with Fine-Grained Notifications - <AUTHOR> https://realm.io/news/marin-todorov-fine-grained-notifications/ <comment><USER2> If you wish you could do that with SQLite, check GRDB.swift. It can synchronize a UITableView with an SQLite query. Demo: [https://github.com/groue/GRDBDemo](https://github.com/groue/GRDBDemo), documentation: [https://github.com/groue/GRDB.swift/tree/v0.70.1#fetchedreco...](https://github.com/groue/GRDB.swift/tree/v0.70.1#fetchedrecordscontroller)</comment>


Engineering at BankSimple - <AUTHOR> http://banksimple.com/engineering/2011/01/03/engineering-at-banksimple/

<comment><USER2> For me the best the part of the post was

"We don't adhere to any specific development process or methodology at BankSimple. We've borrowed bits from processes that we've worked with and enjoyed, and eschewed bits that we think are unnecessary. Our process is always evolving, and I'm trying to provide ample opportunity for feedback and change as we determine what works and what doesn't."

Too many companies/startups set store by thinking whether their processes are agile or not. Or bring in external scrum masters to teach people how to do things and how to follow processes. But lot of people fail to understand that software development is people driven enterprise and its almost impossible to make 2 people work in uniform manner. And worse part if, lot of people think that, if you make 2 people work in same manner, chances of better software are increased multi-fold. Even though there has to be some basic processes outlining how to do things. It all comes down to DNA of the team and what the team is comfortable with when it comes to processes.

</comment><comment><USER3> _After some deliberation, we decided on a JVM-oriented stack. The JVM is not without its quirks and challenges, but it's a mature platform with well-known performance characteristics and a vast archive of libraries, particularly in the financial services world we find ourselves in._

 _We use the JVM in a non-traditional way. Our backend services are written in Scala, Clojure, or a mix of the both (making use of a thin compatibility layer we're developing). Our web frontend is written in Ruby, and can be run on JRuby in production. This polyglot programming approach allows us to leverage the strengths of each language while still operating on a common platform. One could argue that it would be simpler to pick one language and stick with it, but that presumes that all problems are equally well solved in any one language._

Other than the vast archive of libraries, which are not necessarily going to be straightforward or similar to use across the languages on the JVM, one could still leverage the strengths of individual languages while still operating on a common platform, such as x86_64. Does the addition of another abstraction layer that provides the same interface (the languages) but that you don't really interface with directly really have that many (significant or otherwise) advantages?

</comment><comment><USER4> Can someone explain how banksimple is different than everything else? From my understanding it's just got a backing bank and puts a pretty face out for a webui... is that really all?</comment>


Tory conference app flaw reveals private data of senior MPs - <AUTHOR> https://www.theguardian.com/politics/2018/sep/29/tory-conference-app-flaw-reveals-private-data-of-senior-mps <comment><USER2> "Anyone could log in as any attendee by providing an email with no password. Many MPs had registered with their public parliamentary email addresses, making it simple for any member of the public to access their mobile number."</comment>


Steve Ballmer, Meet Ibn Khaldun - <AUTHOR> http://krugman.blogs.nytimes.com/2013/08/24/steve-ballmer-meet-ibn-khaldun/

<comment><USER2> I'm not normally a fan of Krugman but I give him props for pulling Khaldun out.

The entire passage beginning with:

> "This implies that the new rulers are at first considered "barbarians" by > comparison to the old ones..."

was also expounded upon at length by Toynbee in "A Study of History". The 'creative minority' that is the heart and soul of most economic/political efforts (such as building out of the American industrial base in the 19th-20th centuries) later becomes the 'dominant minority' that is more interested in holding the power given to them by previous generations rather than building out the company/corporation/empire. As the dominant minority lose their grip and their power, a new generation of 'barbarians' or outsiders (as viewed by the decaying powerbase) fills the vacuum left by the old elites.

It's a dynamic we see time and again in smaller and larger spheres of human activity.

</comment><comment><USER3> Once upon a time I had the notion that "founding armies" always had an edge over the rest. Alexander -> First army of unified greece. Early Rome. Napoleon -> first unified French army. Bismarck -> first unified German army. Union. Japan in 1905. Red army in russian civil war. US in WWII was still somewhat army of immigrants. Thanks to this article, I can put a name to this effect.</comment>


Cryptanalysis of Enigma - <AUTHOR> http://practicalcryptography.com/cryptanalysis/breaking-machine-ciphers/cryptanalysis-enigma/ <comment><USER2> I just want to mention that this site uses a kind of informed brute-force attack on Enigma. If you're interested in the wide range of techniques used to break the Enigma code in Bletchley Park without the use of a programmable computer (the machine they used, The Bombe, was essentially a bank of enigma wheels, hooked up to wires which generated logic circuits as the wheels rotated) then read Hodges biography of Turing.

If you don't have that exact book to hand, you swine, then the wikipedia page looks comprehensive from a glance, if a bit inaccesible.

[https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma#Cr...](https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma#Crib- based_decryption)

<comment><USER3> The impressive thing about Enigma was that unlike most previous ciphers it was "secure" in the sense that even if you know its implementation details you still cannot break messages without a brute-force search. Particularly when the plugboard was used.

The key mistake was underestimating the ability to automate and parallelize a brute-force search. Turns out a keyspace of 3^26 is just too small. User error was a large contributing factor, of course, and ensured that the implementation details were always leaked. But when it came down to it, the Polish and British intelligence services could simply break the codes on a near-daily basis.

<comment><USER4> Well, also its susceptibility to both known-plaintext attacks and statistical analysis, though it depends a bit if you're talking about the army version of the enigma or the navy version. Also until very late versions, the machine couldn't map a letter to itself, which was another critical vulnerability.

The actual keyspace was around 76 bits [1], which is fairly respectable, particularly for the mid-20th century. Much of the weakness was, in fact, the result of the Enigma being an early device in a nascent technological field -- ie, the result of failures in the Enigma's design, as well as procedures surrounding its operation (not just operator error; for example, Polish cryptanalysts used the procedural repeating of the rotor setting initialization (it's conceptually similar to an initialization vector in modern crypto) to break early versions of the machine as early as 1932.

[1] [https://en.wikipedia.org/wiki/Enigma_machine#Details](https://en.wikipedia.org/wiki/Enigma_machine#Details)

<comment><USER5> Another early device problem was the threat model post WWII is of course nations will put up a near Manhattan Project level of effort which turns out to be just enough to break it, everyone knows that.

Pre WWII of course, they figured if a PHD mathematician couldn't crack it in a couple hours with chalk and chalkboard, well, surely they'll just give up, right?

The ratio of optimism to pessimism was a bit off.

<comment><USER6> > The ratio of optimism to pessimism was a bit off.

Not much has changed then.

</comment></comment></comment></comment></comment><comment><USER7> I was surprised about this bit:

 _It is interesting to note that the actual key settings used the indicator 'SIG' with ring settings 'PMP', but the [different] recovered key gives an identical decryption._

So there are keys of the enigma that produce the same ciphertext? Wouldn't that reduce the practical keyspace dramatically?

Also, would that mean a message could be "hardened" by referring to the original key within it? (E.g. "Execute order <second letter of indicator><first letter of indicator>)

</comment><comment><USER8> David Kahn's books "Codebreakers" and "Seizing the Enigma" are both very good and detailed reads.

</comment><comment><USER9> So reassuringly similar to my own attack on enigma :) [http://williamedwardscoder.tumblr.com](http://williamedwardscoder.tumblr.com)

The thing that helped me most was building a paper enigma.</comment>


Open Source Is Really About Documentation – Twisted vs. Tornado - <AUTHOR> http://www.littlehart.net/atthekeyboard/2009/09/14/open-source-is-really-about-documentation/?utm_source=rss&utm_medium=rss&utm_campaign=rss <comment><USER2> I have built several twisted apps which are in use in production environments, including web and jabber/xmpp apps. I love twisted, and use it whenever possible...

...and I agree completely with the op.

Twisted is powerful, flexible, well architected, and reliable. It is also damn near impossible to get over the steep learning curve and to actually USE it.

Show me a competent Twisted developer, and I'll show you someone who had a gun jammed roughly in their mouth, and was FORCED to learn it at some point. We are all glad we know it _now_, but that learning process SUCKED.

<comment><USER3> [http://twistedmatrix.com/projects/core/documentation/howto/t...](http://twistedmatrix.com/projects/core/documentation/howto/tutorial/index.html)

What's wrong with that? Seems quite comprehensible to me...

<comment><USER4> It's indeed the starting point to learn the fundamentals - but becomes almost hilarious after step 4 when they begin to introduce Components, Adapters, Perspective Broker and other things without losing many words about what all that stuff does, much less how to re-arrange it for custom needs.

The best investment in terms of mindshare the twisted project could make at this point would be to simply sit down and write documentation.

Grab sphinx (or another tool that makes doc-writing fun) and start out by writing a page about each Class that is being used in these examples. Why does it exist, what role does it have and don't forget the link to the API doc. Then I'd suggest to make a high-level overview, perhaps even with a little diagram, that explains how everything plays together in the various application types. Hyperlinks to the previously mentioned detail-pages should then work wonders for anyone exploring the project.

Writing _good_ documentation is hard, but you only have to do it once. The lack of documentation on the other hand forces _every_ new user to wrap their heads around innocent lines like this:

       internet.TCPServer(79, factory).setServiceParent(
           service.IServiceCollection(application))

I'm surely not the only one who put off learning about that whole Service metaphor and stuck with the simpler examples until I absolutely couldn't avoid it any longer. That's not the way you want users to approach your framework.

<comment><USER5> > The best investment in terms of mindshare the twisted project could make at > this point would be to simply sit down and write documentation.

Making documentations (and contributions to it) a first-class contribution with its bugs & discussions & refactorings, and fun to write (the way the Django project handles it) would probably also go quite a way towards that.

<comment><USER4> Yup, agreed. Creating and endorsing good documentation is an artform in itself.

Currently the barrier of entry is too high and I guess too few people are deep enough in twisted to explain all the why's of even a simple baseline example _properly_.

It's kind of a deadlock situation because without that lowlevel insight it's also hard to get confident enough to contribute high-level docs.

<comment><USER5> > Currently the barrier of entry is too high and I guess too few people are > deep enough

Thing is, through checking out Django I realized you don't really need to be "deep enough" to contribute to that stuff. The thousand-cut effects applies, and when you're trying to make heads or tails of the doc, you're bleeding from these thousand cuts so you know and understand the doc's pain points. If doc contribs are first-class, then right as you understand the issues and what the doc tries to say, you'll be steered towards opening a documentation bug (and maybe even contributing a patch) for that part.

Maybe it's just doing to be a bit of wording, maybe it'll be a link or two to other relevant parts of the doc; maybe it'll be things you'll have figured through your sweat and tears, maybe something you'll have learned by asking a question on IRC.

But even as a beginner, you'll have added a little stone and made the doc slightly better through your current understanding. And it's enough.

I barely contributed to Django myself, but my first ever contrib was simply pointing out that the `now` tag's format character `n` produced an RFC 2822 date, not an RFC 822 one as written in the doc at the time. It was almost nothing, but it still very slightly improved the documentation for the next guy reading it, and it actually made me feel involved in the project. Even though I didn't have anywhere near the knowledge of the codebase to contribute to the code itself.

edit: and re the thousand cuts effect, that's the great thing about making beginners contribute: "old timers" don't notice or remember these small issues (which pile up), because they fill in he blanks or missing parts through their knowledge.

</comment></comment></comment></comment></comment></comment><comment><USER6> Not all of Twisted's documentation is bad. And if folks can't figure out the docs, Jean-Paul and Glyph are available to help in IRC and know everything about Twisted (since as far as I know they represent 90%+ of the current contribution and maintenance).

Besides, Tornado can afford to have (seemingly) more comprehensive documentation because it is far smaller in scope and support. Twisted has a large number of robust libraries for doing all sorts of things asynchronously, from web servers to ORMs to SSH and everything in between. It's like comparing an orange to a bushel of apples and it's silly. Twisted has never supplied a web framework, which is exactly what Tornado supplies.

The Twisted docs are lacking in many ways, I just don't understand how Tornado is objectively _better_ because it doesn't currently have that problem -- they aren't the same thing!

<comment><USER7> (Disclaimer - I wrote the blog post)

"The Twisted docs are lacking in many ways, I just don't understand how Tornado is objectively better because it doesn't currently have that problem -- they aren't the same thing!"

Of course it's the same thing. If your documentation is lacking, don't complain when people point it out. It's awesome that Jean-Paul (who commented on the blog post) is available to help people...but if there was more documentation then the simple questions disappear and you are left answering the really tough ones. Easier said then done, obiously.

Upon reflection, this is really a comparison of Twisted.web with Tornado. The rest of Twisted got dragged into it, perhaps unfairly.

</comment></comment><comment><USER8> Blogging Is Really About Whining.

There seems to be a segment of the programming society that's just content with spewing whinage about not being able to get what they want, instead of using what they find and improving it to fit their needs.

I am no Python programmer, but i have looked at twisted and found it trivial to grok. I saw how they have wrapped the Unix system calls and put a layer of abstraction over it .. I didn't like it, and went back to using Common Lisp's iolib. I must have missed an opportunity to blog there :-(

<comment><USER9> I think you're taking a reductionist view, and I think you've missed the point the author was making. The author first expressed his understanding of the influences on individual behavior and then he made specific suggestions (with examples) of how twisted had failed to optimize for a specific outcome within that framework.

I consider this analysis and feedback, not whining.

You seem to suggest that the author is whining in lieu of being self- sufficient. I can't speak for the author, so I will just speak for myself. I wholeheartedly believe in the self-sufficiency that programming culture promotes. However, I also believe that the easier you make it for others to achieve self-sufficiency in your open-source library, the more successful it will be.

I'm happy that you found it trivial to drink deeply of twisted's essence. I also think that you are right that you have an opportunity to blog! I for one would _love_ to read about why you think that CL's iolib is a better abstraction layer than twisted. You haven't missed the opportunity -- I'd upvote that over most of the stuff on the front page!

</comment></comment><comment><USER10> As usual, a simple "this versus that" comparison is only useful as an intellectual exercise.

Tornado is a web framework, in many ways closer to Django than Twisted. Beyond that the underlying approaches are different - Tornado does not use deferreds.

There are a number of great projects that use Twisted. Soon many new projects will use Tornado. But the frameworks' respective documentation does not tell the story.

<comment><USER5> > Tornado is a web framework

Not really. It's the combination of an asynchronous HTTP server and an optional web framework. And work is being done [to add WSGI support]([http://github.com/facebook/tornado/commit/8ca616088cfb26ff19...](http://github.com/facebook/tornado/commit/8ca616088cfb26ff19fcc6f359d654fef905b8da)) so other frameworks can be plugged into the server.

At its core, Tornado is a server not a framework.

<comment><USER10> The Tornado front page refers to itself as a framework six times, but we're splitting hairs.

Twisted is, at least for now, more general purpose. Can't wait to see where Tornado goes though.

</comment></comment></comment><comment><USER11> It's obvious, documentation is always important. It's even more important for proprietary software, since you can't even study the source. But it seems that neither of this two projects has good and extensive docs/tutorials.

You could argue that if Twisted was better documented the FriedFeed guys wouldn't have started their own project. I don't buy it. There could have been many (technical and non-technical) reasons to do this anyway.

I (mostly) agree with a comment on the blog: _This is just pure NIH syndrome. It happened because it's easier to write code than to read it, and it's more fun to create than to fix._

</comment><comment><USER12> I'm sorry, but <http://twistedmatrix.com/trac/wiki/Documentation> is the documentation, where I started and it shows nice examples, a high level introduction -- everything needed to dive in. Actually I learned a whole lot back in the days when I had to use this fine documentation.

</comment><comment><USER13> I think a bit of friendly competition will help both projects.

The Twisted devs may have some hurt feelings, but I think they can learn a lot from this.

</comment><comment><USER14> Well, I think when friendfeed developers were writing tornado they didn't mean to opensource it or even talk about it in public, so they went for the name "Tornado".

I agree that documentation is really important in Open Source, and so is _finding_ the documentation. Googling for such a generic names makes things hard. Considering all the hype Tornado got recently the homepage is not still listed in the first 5 pages of Google's results for "Tornado".

So I think it's a good advice to think twice (or thrice) before naming your next project.

</comment><comment><USER15> I don't think the "documentation sucks" can be used to model very well the issue, there is another very important thing: is it simple to use, and the base case is obvious, or is it over engineered? I think in the Twisted / Tornado issue there is some of this elements too.

A lot of libs around here are, technically speaking, well coded, reliable, fast. But the API sucks. An example is the libpng, if you have some experience with it you'll understand. When an alternative with a clean API arise it's very hard to resist.

</comment><comment><USER16> Just remember MySQL - its success was about documentation (the most), community (as a result) and some PR.

It is so strange to create reusable components without detailed guides.

The nginx had this very problem. If it could get a user-friendly documentation it will earn more adoptions.

<comment><USER17> I also think this was one of the factors in PHP's popularity. Its documentation was (is?) excellent.

</comment></comment><comment><USER18> Every time I've thought about using Twisted for something, I go back to their documentation and remember why I wrote it myself with asyncore last time.</comment>


Show HN: Custom Tooltip Generator on Vue.js - <AUTHOR> https://viashchuk.github.io/tooltip-generator <comment><AUTHOR> Hello everybody!

I created a tool to generate custom tooltips. It's my first post here. I hope this will be helpful to you.

Site: [https://viashchuk.github.io/tooltip- generator](https://viashchuk.github.io/tooltip-generator)

Github repo: [https://github.com/viashchuk/tooltip- generator](https://github.com/viashchuk/tooltip-generator)

Feel free to leave a comment or review

Thanks, Victoria

<comment><USER2> Looks quite nice, its a bit confusing on your site though that the tooltip just always displays, I think you should add a toggle so it works as a tooltip there also :)</comment></comment>


Rice Uiversity Announces Open Source Textbooks - <AUTHOR> http://www.insidehighered.com/news/2012/02/07/rice-university-announces-open-source-textbooks

<comment><USER2> The Connexions platform has been around for a while now, and as I recall students whose classes used it were happy with it, from both a price and usability standpoint. Glad to see that the program is getting more ambitious -- the move ties in nicely with the backlash against Elsevier. The rise of open-source competitors to academic content providers seems like a huge win for students and institutions alike.

</comment><comment><USER3> Wow. I wonder if "algebra-based" means "no calculus". <http://openstaxcollege.org/textbooks/college-physics>

<comment><USER4> At my school, yep. There were two tracks: Physics for scientists and engineers, which used calculus, and physics for arts/humanities, which was "algebra based".

</comment></comment><comment><USER5> If the publishing industry has anyone with half a brain working for them, they should see themselves going the way of the music industry. They need to innovate fast. Open source books are only part of the problem (and by problem, I mean only their problem). It is becoming easier and easier to find torrents to download full color versions of many of the most popular textbooks.

</comment><comment><USER6> Go Rice! This has been a long time in coming. Lots of undergraduate classes will be hugely benefited by this sort of effort.

</comment><comment><USER7> I remember classmates coding for the Connexions platform just over a decade ago. Here's the announcement and video that Rice University just posted:

[http://www.media.rice.edu/media/NewsBot.asp?MODE=VIEW&ID...](http://www.media.rice.edu/media/NewsBot.asp?MODE=VIEW&ID=16745&SnID=1521497554)

</comment><comment><USER8> The OpenStax publications look most interesting, alas, the e-mail notification form will only accept US zip codes.

<comment><USER9> Not sure why that's a problem, since that field is optional.

<comment><USER8> True, but it does 'send a message' if you see what I mean.

</comment></comment></comment><comment><USER10> Anyone see the list of textbooks? I couldn't find it.

<comment><USER9> Click on the orange "our books" button. It will take you to:

<http://openstaxcollege.org/books>

</comment></comment><comment><AUTHOR> I'm looking forward to when this hits high school.

<comment><USER11> ck12.org</comment></comment>


Realtime funnel analysis using Solr and Cassandra - <AUTHOR> http://blog.getjaco.com/analyzing-funnels/ <comment><USER2> >For funnel analysis, it's not feasible to use this data model for getting back a summary of the funnel steps and the sessions matching it, since there's no option in Solr to run a recursive query, which would allow to go over each session and check if it's a match for the funnel.

I don't think this approach scales, even in an environment that supports recursive queries like PostgreSQL.

The more scalable approach would be to use either a commercial database systems with explicit support for pattern matching or encode conversion path as a string (ex: "top page -> product page with SKU=1337 -> Purchase" becomes "T_SKU1337_P") and use REGEX/GROUP BY.

In all cases, this sounds like a suboptimal use case for either Solr or Elasticsearch.

<comment><USER3> Why do you think this approach isn't scalable? would love to hear your input on that. Also what commercial database systems do you think will be good for this?

<comment><USER2> The suggested approach most likely requires a lot of recursive backtracking. Of course, there's an efficient way to implement this, and that's what most commercial databases' path analytics features do. Here's one example by Oracle: [https://docs.oracle.com/database/121/DWHSG/pattern.htm](https://docs.oracle.com/database/121/DWHSG/pattern.htm)

I've always found it befuddling why so many developers want to use Solr/Elasticsearch for analytics heavylifting. It's probably because

1\. SQL is not the most intuitive (although most pervasive) API for data analysis

2\. Much of the data is already in Solr/Elasticsearch to make your data searchable/perform simple roll-ups and filtering, etc., so it'd be great if you can do more complex analytics against them as well

AS to why Solr/Elasticsearch is not ideal: the existence of superior alternatives that is OLAP databases.

</comment></comment></comment><comment><USER4> Why do people use C* in addition to ES? It seems like in this case most of the data could directly be piped into ES?

I understand that ES can lose data, or have some data storage problems, but one could just as well store all the incoming data on Hadoop or so, without having to bother with C*, no?

<comment><USER3> C* makes it much easier to manage a cluster of Solr as the data grows (specifically with DSE), as with the tight integration you get all the benefits of C*. (HA, eventual consistency, multi-dc replication..)</comment></comment>


What is tech stack of HackerNews? - <AUTHOR> what is tech stack of HackerNews? php?? <comment><USER2> HN is one of the few places Arc, pg's own dialect of lisp runs in production.

Check out pg's page on arc to learn more: [http://www.paulgraham.com/arc.html](http://www.paulgraham.com/arc.html)

This is a good place to start: [http://www.paulgraham.com/hundred.html](http://www.paulgraham.com/hundred.html)

One of the other places arc runs in production is the arc-forum: [http://www.arclanguage.com/forum](http://www.arclanguage.com/forum)

Arc-language github: [https://github.com/arclanguage](https://github.com/arclanguage)

</comment><comment><USER3> Arc ([http://www.arclanguage.com/](http://www.arclanguage.com/)), I believe, running on top of Racket ([https://racket-lang.org/](https://racket- lang.org/)). Unless they changed it since it was made public.

</comment><comment><USER4> [https://en.wikipedia.org/wiki/Arc_(programming_language)](https://en.wikipedia.org/wiki/Arc_\(programming_language\))

</comment><comment><USER2> Here's a look at the actual out of data source: [https://github.com/arclanguage/anarki/blob/master/lib/news.a...](https://github.com/arclanguage/anarki/blob/master/lib/news.arc)</comment>


AWS Snowmobile – Move Exabytes of Data to the Cloud in Weeks - <AUTHOR> https://aws.amazon.com/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/ <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=13073176](https://news.ycombinator.com/item?id=13073176)

</comment><comment><USER3>
        Never underestimate the bandwidth of a station wagon full of
        tapes hurtling down the highway.

—Tanenbaum, Andrew S. (1989). Computer Networks. p. 57.

<comment><USER4> Never underestimate the street value either. I wonder if they have an armed escort for this truck -- the hardware must cost on the order of 10-20 million, and the data itself could be worth many multiples of that. Could make a great heist movie.

<comment><USER5> I wonder if Amazon pays for the re-do if the truck ends up in a spectacular accident.

<comment><USER6> Can't one simply mirror a Snowmobile to a second Snowmobile prior to transport?

<comment><USER7> Redundant Array of Independent Trucks?

</comment></comment></comment></comment></comment><comment><USER8> As other commenters noted, it's fascinating that no matter how advanced the networking technology progresses, we'll always have a variation of "sneakernet"[1] to bypass the limitations of the network. The sneakernet just evolves from floppies to 45-foot shipping containers.

If humans later colonize Mars and want to have the full 50-terabytes copy of Wikipedia in the biosphere, it's faster to send some harddrives as a rocket payload on a 6 month journey rather than try to transfer it via the 32kbps uplink[2] which would take ~500 years.

[1] [https://en.wikipedia.org/wiki/Sneakernet](https://en.wikipedia.org/wiki/Sneakernet)

[2] [http://mars.nasa.gov/msl/mission/communicationwithearth/data...](http://mars.nasa.gov/msl/mission/communicationwithearth/data/)

<comment><USER5> A screenshot of Tanenbaum's _" Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway"_ argument with the context around it from his book.

[http://imgur.com/a/qi4BP](http://imgur.com/a/qi4BP)

<comment><USER9> A thing bothers me regarding that calculation. Shouldn't the time it takes to _write_ the data to all those tapes be taken into account? I.e., if you're using tapes to transport data, your real bottleneck is your tape drive write speed.

<comment><USER5> Perhaps an artifact of the time period. In the 90's, you likely already did backups to LTO/Ultrium tapes daily. So the time was considered already sunk cost.

</comment></comment></comment></comment><comment><USER10> I feel unusual when I see articles like this. I deploy "workloads" that require instances, auto scaling, Multi-AZ etc. It makes my projects feel minuscule at the scale of other companies that actually use something like this! I wonder how many companies will actually use this in any given year.

<comment><USER11> I imagine surprisingly many. I have operations that are not remotely on that scale. 8 employees with total data on the order of tens of terabytes. I found that to be a surprisingly heavy density of data per employee. A 1000 employee company with the same density is on the petabyte scale.

</comment></comment><comment><USER12> I wonder why this makes sense. Isn't it more useful to get a few hundred snowballs and ship them via Fedex? You can transfer in parallel and should be at the same speed as with Snowmobile. It's at the DC next day and the data will be faster in S3 than by truck. Also, the economies of scale will never pay off for Snowmobile, likely more for Snowball.

At the same time, logistics (incl insurance and security) is handled by companies that are very good at it. Fedex, DHL and the like offer physical security services for goods if you need it in addition to encryption.

Think it's a PR move only. They will probably find a few clients to somehow utilize one truck, but I don't think it's more efficient than Snowballs.

<comment><USER13> Installing, powering and cabling "a few hundred" of anything in a datacenter is a big deal. You probably don't have room. You may not have power. You have to deal with hundreds of boxes, cardboard isn't allowed on the datacenter floor (ideally), and just mucking around on the loading dock wrangling stupid stuff like shipping labels is going to suck up a ton of time.

[I'm a C++ dev who likes to help design and build datacenters. It's fun.]

<comment><USER12> But isn't that the same problem with the truck? You also need to get that connected to the datacenter for a week? I guess as that connection has to leave the building, it should be even harder?

<comment><USER14> Just run a conduit of fiber out to the parking lot temporarily.

</comment></comment></comment></comment><comment><USER15> Unless my math is wrong, storing 100PB in S3 is something like $2,750,000 per month.

Then what happens in 5 years if local storage cost dropped by a factor of 10, but S3 cost did not drop?

Big risk, no?

<comment><USER16> If somehow a technology is developed to allow local storage cost to drop by a factor of 10, don't you think S3 would make use of the same technology to stay competitive?

Cloud storage is a commodity these days. The market saves you in this case -- if one cloud provider didn't use the 10x technology and pass along the 10x savings to the customer, another company would do it and steal all of their customers.

<comment><USER17> You'd still need to get your data out of Amazon's cloud and into the competitor's. That's neither cheap nor easy.

<comment><USER16> My point is that _all_ cloud competitors would necessarily switch for economic reasons. If not to keep you from leaving, then to keep a competitor from capturing all _new_ growth.

<comment><USER15> Thats not how it works. People still use IBM mainframes, despite linux being 10x cheaper or more. If you got locked in sometimes you get locked in.

Many AWS services have no easy migration path off it.

<comment><USER16> That's absolutely how it works.

If a 10x cost reduction storage technology comes along, cloud providers _will_ necessarily adopt it and _will_ reduce their prices by approximately 10x.

Here's why:

\- If they don't, it will become more cost effective for potential customers to run their own datacenters rather than put data into the cloud, so their growth will basically stop.

\- Even if potential customers don't want to run their own datacenters, both potential and _existing_ customers will put new data to a competitor who _did_ pass along the 10x savings to the customer. So again, their growth will basically stop.

This is the nature of a commodity product in a free market. Basically all cloud providers use an S3-compatible API, and costs and performance are in the same ballpark. There are tons of open source compatibility layers that abstract which provider you are putting to. If one of them starts costing 10x less, you just flip the switch and all new data goes there.

The ability for customers to completely cut off growth of their service if prices don't fall is a supreme motivator. The only case this wouldn't be true is if all of the cloud storage services formed a cartel to fix prices. But given that every time Google or Amazon lowers prices, the other one follows to maintain parity, we have evidence that that isn't the case.

Addendum:

I don't understand your analogy at all. IBM mainframes are a specific type of hardware that excel at highly available batch and transactional processing. Linux is an operating system. Linux is free, so it's infinitely cheaper. Also, IBM mainframes run Linux.

<comment><USER15> > If a 10x cost reduction storage technology comes along, cloud providers will > necessarily adopt it and will reduce their prices by approximately 10x.

Here are my two counterpoints.

1) Bandwidth prices HAVE fallen 10x in the past N years. Many cloud providers (ovh, etc) DO offer this price drop. Yet how many people really left AWS or GCE for ovh? I would guess not that many.

2) As I said with mainframes.. there is a 10x cheaper option to a mainframe that has been around for oh 15 years. But people are still on them, BECAUSE they are still locked in to them. That is my point. Don't get locked into a single anything. Sending 100 PB data for a commercial entity to hold for you, with no guarantees of future pricing, is a bad move. Locking yourself in is one of the worst things you can do as a company.

<comment><USER16> @1: That doesn't directly address either of my points. You're just providing an orthogonal example of a something that cloud providers didn't move on.

I agree that the bandwidth pricing is almost certainly designed to create lock-in. What I am contending is that that is unrelated to the storage pricing. You'll notice that my arguments didn't include bandwidth pricing at all, because it is irrelevant to those arguments.

I'll give a more concrete example. Let's say I want to transfer 10PB out of S3. On their pricing sheet they actually say to contact them to get a quote, but before that the prices are dropping pretty fast as you get more data. e.g. 10TB is 9 cents per GB, but after you get past 300TB you're paying 5 cents per GB.

Let's be pessimistic and assume 5 cents per GB, even though you could probably get it for much cheaper by contacting them.

So 10PB will cost me (10PB * (5c/GB)) = $500K to export

Standard storage is about 2 cents per GB. So your 10PB sitting in S3 is costing you 200K / month just to sit there and do nothing.

Do you see the problem here? Moving onto the 20K / month provider becomes cost-positive after 3 months.

Even if they were to _increase_ bandwidth costs 10x, it'd still become cost- positive in a relatively short amount of time (couple of years).

Furthermore, if you are paying S3 millions of dollars per year to store data, you're almost certainly in a position to get them to contractually agree to that cheaper-than-public bandwidth cost I mentioned earlier, so you don't even have to worry about the situation in which they hold you hostage by increasing bandwidth costs 1000x.

 _Yet furthermore_ , to reiterate my previous point even if they were to increase bandwidth costs 1000x on normal customers that didn't have enough clout to get contractual guarantees, that would kill their business. Nobody new would put any new data in them. Sure, they could hold the existing data hostage, but absolutely nobody is going to put any new data there.

Similarly, if they were to not decrease storage costs 10x compared to a virtually-identical competitor, nobody would put _new_ data with them. This is the part that is totally unrelated to bandwidth costs. Everyone would start putting all of their _new_ data into the competitor, regardless of their old data being locked in.

The fact that Amazon and Google both immediately reduce storage prices after the other one does is evidence that this is the case.

@2 I think you underestimate mainframes. People who use them aren't totally stupid. They do a specific thing very well. Right tool for the job and all that.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> A surprising number of comments are questions that are answered explicitly in the article.

PSA: consume the full content before you comment on the content.

</comment><comment><USER19> >> We needed a solution that could move our 100 PB archive but could not find one until now with AWS Snowmobile.

Around this time last year BackBlaze had 200PB of customer backups. They described storing it on _54,675 hard drives across 1,215 Storage Pods_

So imagine 600 storage pods or half of BackBlaze's entire operation, for just one customer. Insane.

</comment><comment><USER20> I love how this is a literal trailer pulled by a truck - see the pictures at [https://aws.amazon.com/snowmobile/](https://aws.amazon.com/snowmobile/).

I wish they gave more details as to what hardware was in there - are there any pictures of what the trailer looks like on the inside?

<comment><USER21> So sneaker net was once someone walking around with burnt CD-ROM, then it was a box of drives, and now its a truck.

Quite a dramatic illustration of the increase in data usage.

If one extrapolates next stop will be a train, and then a container ship full of hard drives.

<comment><USER22> > then it was a box of drives, and now its a truck.

Between that was FEDEX-ing a NAS. That's pretty much the standard data- exchange format in astronomy, so you have a fast link and don't need to bother plugging a bunch of drives in, just plug the NAS to the power and network and off you go.

<comment><USER21> Hmmm....

So when will The Universe be too small to data considering data use is exponential.

I imagine there are lower upper limits, but this would be the upper upper limit.

</comment></comment></comment></comment><comment><USER23> This really helps me, personally, abstract the concept of 'data' a lot more. It's not about files or records, data has a 'volume'. A few PB fills up a shipping container.

Next time my client asks me how "much" a PB is, I can just say "about a shippingcontainer's worth".

<comment><USER24> But bytes/volume isn't a constant. You may be able to say a 100 PB is equal to about a shipping container now, but in 10 years it will be much smaller (probably not keeping up with Moore's Law for storage though).

<comment><USER22> Even then it depends on medium, an LTO-7 or HDD can store ~26GB/cm3 while an SDXC tops out at around 1TB/cm3.

</comment></comment></comment><comment><USER25> Every blog post should have a Lego visualisation like this.

<comment><USER26> Agreed! But for the love of LEGO, after all that effort to make great custom scenes, they could have used a better camera!

Those photos look like they were taken with a poorly focusing cheap smartphone.

</comment></comment><comment><USER27> 350KW seems a bit high for something that should effectively be an append-only file system. I would have expected 95% of the trailer to be in standby at any point in time.

<comment><USER28> Yeah, thought that number was a bit high. Maybe there's something else to it?

<comment><USER29> Encryption.

<comment><USER6> Air Conditioning.

</comment></comment></comment></comment><comment><USER30> While I admit that there may be customer demand for this, even if there is not, Amazon has certainly made a great marketing message.

<comment><USER31> There is: DigitalGlobe is/was using it.

</comment></comment><comment><USER32> Now _this_ is real persistent container storage. ;) And persistent it will be, because even at 1Tb/s it will take you over a week to load the data onto it. The bandwidth while in transit is phenomenal, but before that it will be sitting at your DC's loading dock for quite a while.

</comment><comment><USER33> So- suppose we could move that same 100 PB in a standard 24" cube FedEx box, collecting the data in less than a week and using only two 110v power connections. Would that be interesting? Oh, and it takes less than a single rack of gear.

</comment><comment><USER34> Any idea on the type of link they are using to connect to the containers ?

If they fill the thing in 30 days, that average to 40 Go/s, way faster than 10gbe or Fibre Channel.

<comment><USER35> > Each Snowmobile includes a network cable connected to a high-speed switch > capable of supporting 1 Tb/second of data transfer spread across multiple 40 > Gb/second connections. Assuming that your existing network can transfer data > at that rate, you can fill a Snowmobile in about 10 days.

</comment></comment><comment><USER36> [https://tools.ietf.org/html/rfc1149](https://tools.ietf.org/html/rfc1149)

</comment><comment><USER37> Maybe someone at Amazon was reading xkcd[1]

1\. [https://xkcd.com/949/](https://xkcd.com/949/)

<comment><USER38> Even before Snowball was launched the import/export team was joking about UPS trucks full of snowballs, both within the team, and then with management. I guess management found out there was actual customer demand for it.

</comment></comment><comment><USER39> Because it's a shipping container, maybe eventually they'll do worldwide data transfer?

<comment><USER12> Probably by plane. Shipping would otherwise probably be slower than using the network.

<comment><USER22> Worst case shipping is ~30 days (e.g. China to Hamburg), which is 38.6GB/s for 100PB in a container.

I doubt you have a permanent dedicated 40+GB link between you and the nearest AWS data center.

Shipping by boat would still be way faster than a network upload.

<comment><USER12> You are correct, I had my math wrong. But don't know if they're certified for shipping, not sure how the sea transport would affect the drives?

<comment><USER22> Well if the container is completely and securely sealed it should not affect the drives, after all the drives or other parts are shipped from factories.

But yeah I'd expect air-shipping as well, if only so that the container can be kept secure, I doubt Amazon is going to send security personnel for week-long trips on cargo ships.

</comment></comment></comment></comment></comment><comment><USER40> Whoever said "The Internet is not a truck"? Seems like this blurs the lines a bit :)

</comment><comment><USER41> I'd love to see actual pictures of that truck :)

<comment><USER5> [https://techcrunch.com/2016/11/30/amazon-will-truck-your- mas...](https://techcrunch.com/2016/11/30/amazon-will-truck-your-massive- piles-of-data-to-the-cloud-with-an-18-wheeler/)

</comment></comment><comment><USER42> So this is absolutely a honeypot then, right?

There's no way to verify that this truck full of my corp's valuable data isn't stopped somewhere along the way and cloned and then driven to NSA or something.

<comment><USER5> You're putting it in the truck with the intention of shipping it to Amazon to load it onto their infrastructure. If you don't trust Amazon with your data, the truck isn't unique in any way...they can clone your data at their data center too.

<comment><USER42> Well that's what I'm saying. I mean I guess that rabbit hole goes all the way, even if Amazon brought their machines to me, there's still not a guarantee that it won't be stolen somehow.

</comment></comment></comment><comment><USER43> I wonder how long it takes to load all the data in the truck (over 10GbE? or are there better ways?)

<comment><USER35> Right there in the article.

> Each Snowmobile includes a network cable connected to a high-speed switch > capable of supporting 1 Tb/second of data transfer spread across multiple 40 > Gb/second connections. Assuming that your existing network can transfer data > at that rate, you can fill a Snowmobile in about 10 days.</comment></comment>


Drop Table "Companies";– LTD - <AUTHOR> https://beta.companieshouse.gov.uk/company/10542519 <comment><USER2> I wonder if just the existence of this is evidence of an offence under the Computer Misuse Act?

Sure it failed but the attempt was still made.

</comment><comment><USER3> Always sanitize.</comment>


The joy of Perl - <AUTHOR> http://www.salon.com/1998/10/13/feature_269/ <comment><USER2> This article is from 1998. A lot has changed since then: Ruby, alternate JVM languages like Clojure and Scala, C#, Perl 6... If I were to make a sweeping historical characterization, I would say that Perl was exactly what people needed in the 1990s when everything was new and nothing worked with anything else and everyone needed lots of duct tape and Perl's wonderful concise syntax made excellent duct tape. I used it during that period, but I just don't use it much anymore.

<comment><USER3> Perl 5 also changed a lot since then. And it is definitely not just duct tape anymore (if it ever been)

</comment></comment><comment><USER4> I wonder how many others caught Wall quoting Lewis Carrol....

I suppose Carrol and Tolstoy are to be quoted when asking a natural language guy about computer languages.... ;-)

Honestly, for the last 6 years I have been doing mostly Perl programming (and managing an open source project largely written in Perl) and if I can't easily read a contribution easily I push back.... Perl doesn't have to be hard to read. I would say, however, that keeping things minimalistic is a real virtue in the language.

<comment><AUTHOR> Well why does Perl win:

Ready for this?

The way I see, Any other way of doing regular expressions sucks more badly. In fact if you are look to replace your regular expressions with something else you are likely to inherit a thick verbose pile of junk. Now why do regular expressions work.

Look at this thing below:

        $line =~ m/<some regex>/;

This can also be written as,

        $line =~ m'<some regex>';

or

        $line =~ /<some regex>/;

This matches the line with <some regex>, Why is this special? Because it just allowed to you match a line without first compiling the regex, and then matching it. Not just that it saved you from writing several tens of lines of code before using a regex which you generally have to do in other languages. So you can do something like:

        if ($line =~ /regex/)
        {
        }

or

        do_something() if $line =~ /regex/;

This is a bit of natural language way..

In case of file operations:

        while(<FILE>)
        {
            chomp;
            #Do your stuff
        }

There are some amazing things that Perl does like

        my @file_content = `cat somefile`;

Suddenly all contents are in an array in your program.

Worried about removing new lines from that array? Just do

        chomp(@file_content)

Want to go over that file now? Just do

        foreach my $line(@file_content)
        {
            #Do your stuff here
        }

Want to deal with that line? You have,

        my @fields = split( /<some regex>/, $line );

Want to do more matching/extracting from lines?

        my @processing = map { do_something($_) } @fields;

Want to find something in that array?

        my @results = grep { /some regex/ } @fields;

Want to handle exceptions?

        eval
        {
            #Some operation
        }
        if $@
        {
            #Handle exception
        }

        open( FILEHANDLE , '<' , $file ) or die "Cannot open file";

Just felt the need to create a small database?

        use strict;
        use warnings;

        use DB_File;
        use Fcntl;

        my %some_hash
        tie (%some_hash, "DB_File", $dbm_file, O_RDONLY or die "Unable to open dbm file $dbm_file: $!";
        #change your hash
        untie(%some_hash);

You just got a key-value database.

Want to execute a shell command?

        `/some/command/execute`;

or

        system('/some/commmand/execute');

Need to create a function?

        sub function_name
        {
            my ($var1,$var2..) = @_;

        }

Need to create a Class or a Package?

        package Name;

        #do stuff here

        1;

You can also create anonymous functions

        my $function = sub {};
        $function->();

This also means you can create a closure:

        sub function1
        {
            my $function = sub {#does something};
            return \$function;
        }

In latest versions of Perl, there are some cool features like:

        given($some_data_structure) #what ever that is array, reference etc
        {
            when ( #some match operation ) { #do something }
            ...
            ...
        }

this serves both as a smart matching loop/switch statment.

All the above gives you quick scripting tools.

You also have your usual set of ternary operator,if..else, you can also quote regular expressions.

Now why did I write this, I wrote this to tell that. Perl's motto is to get stuff done. In a no BS way. It adapts to your style, its Object oriented, its functional etc. You decide the style the language bends to you.

You get Best of the OO features from Moose(<http://search.cpan.org/~doy/Moose-2.0402/lib/Moose.pm>), You get modules like Devel::Declare and DBIx::Class, You also get a framework like catalyst. At the same time you can write in funtional programming techniques. You can do cool stuff like Memoization and higher order parsing. For more information read Mark Jason Dominus's Higher order Perl - (free ebook) <http://hop.perl.plover.com/>

At the same time you as a novice can begin with programming with what you understand Read Chromatic's Modern Perl Book - (free ebook) - <http://onyxneon.com/books/modern_perl/>

You can do Object oriented programming, Functional programming, Declarative programming all without shoe horning things using frameworks. You can build big to medium sized apps. Its difficult to demonstrate all that in a post, Hence read MJD's book.

But at the very same time you can use it as a scripting language in which you can cook scripts are at a very quick pace, You can quickly prototype, solve data/text processing problems. You can make it behave like awk, sed and what not. You can create quick databases.

No wonder its still among the top programming languages in the world even after 25 years since its release.

Last but not the least, Its killer app : <http://www.cpan.org/>

<comment><USER5> I agree Perl is great for everything listed except:

        sub function_name
        {
            my ($var1,$var2..) = @_;

        }

I know why methods are like that, but it doesn't make me any less unhappy to have to read a function in order to figure out what types and what order I need to pass values to a function.

There's a few Perl programmers at work who end up using just a bunch of global variables instead of doing pass by reference or returning values from subs.

sub do_something { # modify %my_global_hash }

It's just strange working with Perl after working in more OO languages. But, like you said, Perl adapts to your style. I want it more like other languages I've written in, whereas the people I work with don't.

Getopts::Long is amazing for parsing command line, and I don't know how I would work without being able to do the inline if and unless statements.

<comment><USER6> <https://metacpan.org/module/Function::Parameters>

There are other modules out there like this, including one that bakes it into Moose methods. This also highlights a cool Perl feature: hack able syntax.

<comment><USER7> There are lots of other modules

<https://metacpan.org/module/Method::Signatures> <https://metacpan.org/module/MooseX::Method::Signatures> <https://metacpan.org/module/Method::Signatures::Simple>

and many more. In this case, there might be too many ways to do it.

</comment></comment></comment></comment></comment><comment><USER8> > "We sell the bestselling books on both Perl and Python," adds O'Reilly, "and > what we see is a continued healthy growth in the use of Perl, while Python > use is flat. Perl is orders of magnitude more widely used than Python, and > we see no signs of that changing, at least based on book sales."

I wonder if the difference in book sales is at least partly an artifact of the relative difficulty to learn Perl compared to Python.

<comment><USER9> I find perl substantially more approachable than Python, provided I don't have to read anyone else's code.

<comment><USER8> > provided I don't have to read anyone else's code.

That's a hell of a caveat. :) As I get older, I find I spend more time reading code than writing it (even though most of it's my own), and I find Python's sheer readability indispensable.

<comment><AUTHOR> Its not, basically because if you have bad programmers working for your then you have bigger problems than choosing a language.

And if you have good programmers, then readability isn't a problem. Not even a thing to think about.

<comment><USER10> >>And if you have good programmers, then readability isn't a problem

Hrm, I'd argue against that.

I know better programmers than me, whose code I _hate_ to work with. Also for Python.

But you seem to define "good programmer" as someone who also comments and documents, so I guess you're by definition correct. :-)

Edit: Yeah, "itsnotme". The fault is rather the idiot bosses that let the smart idiots get away with it... But with non-idiot bosses, you won't have readability problems in Perl either.

<comment><AUTHOR> According to me good code is what makes the comment unnecessary. And writing such a thing requires understanding many things. And those things are language agnostic.

Like some one mentioned in this thread, languages tend to be judged by the quality of code produced by their worst user.

For once you can write unreadable code in any language. Even in C and Lisp. In fact there you can create bigger problems and more unreadable code.

<comment><USER10> You _still_ needs comments that tell what the content of a code file is supposed to do, no matter how clear the code is.

(And in scripting languages which doesn't declare parameters, like Python and old style Perl, you need to document what the parameters are.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I do have to admit that Perl had a fun, free-spirited feeling to it that I've not found in any other programing or scripting language. It was fun. Python is close, but a bit too rigid and takes itself too seriously.

Edit: I don't mean that as a criticism of Python. I use it daily and like it. It's just that Perl _was_ more fun. That's all I mean to say.

<comment><USER12> Python does an admirable job of being pretty fun to hack in (you're right, not as much fun as Perl, but not bad), but the end result is that the code is far more readable for others and I think works a bit better in large scale production environments. Perl has come a long way as a response, but there's no doubt that Python ends up with cleaner code.

<comment><USER4> Perl is still an _excellent_ glue language.

The way we are moving towards things in LedgerSMB is:

Web and file format (csv, latex, etc) templates in TemplateToolkit

Everything that can be done as set operations in the db in the process of storing/retrieving info is done in PL/PGSQL.

A brief framework written in Perl

And the rest of the Perl code essentially is written to be very light-weight automation glue between these layers.

</comment></comment></comment><comment><USER13> FYI the article is from 1998. I did a double take when I saw this line.

"Wall has Caller ID hooked up to his computer, which he has instructed to emit unique sounds for each incoming call. What good is Caller ID, asks Wall, if you have to walk all the way over to the telephone to see who is calling?"

</comment><comment><USER14> The readability point is key, will anyone ever write an article extolling "the joy of someone else's script whipped up Perl"? Red Hat and Ubuntu both use Python more than Perl when they want something over and above Bash.

<comment><AUTHOR> I've never had problems reading Perl anymore than I've had reading code in some other language.

<comment><USER15> You've been lucky, then. I love Perl, but there are so many ways to do it you're bound to run into someone who does something in an entirely different way than you. The worst experience I had with this was a colleague who knew the entire Camel book by heart and insisted on using every damn trick there was. He was fired very quickly as the code he produced was impossible for a more normal person to understand

<comment><USER16> Your anecdote implies that we judge the language by its worst user :)

</comment></comment></comment></comment><comment><USER17> I'm a Ruby guy, with no experience with Perl - so no comments on that front. The part I really like about this story is David Filo's gesture of gratitude to Larry Wall. That's a great karma story that warms the heart.

<comment><USER18> You may also find this video of interest: _Clay Shirky on Love, Internet Style_ <http://www.youtube.com/watch?v=Xe1TZaElTAs>

<comment><USER17> Thanks, that was an inspiring video. I've already come to appreciate the power of community (love, according to Clay :), in communities like dd-wrt and cyanogenmod where the quality of collectively contributed firmware beats by miles that provided by the parent hardware vendors. And what's even better is that those enjoying these benefits are willing to give back - best example was when cyanogenmod called for contributions to buy new servers recently. The response was overwhelming and they received more than they needed in no time at all.

The other nice story carried on HN was how Linux Torvalds was remembered by the Red Hat folks with a nice payback in shares as a thank you for everything he did.

The internet really helps too, allowing a dollar here and a dollar there to really add up when genuinely appreciative people make voluntary donations. Bram Cohen is a good example here, who receives well deserved donations from all the folks who love bittorrent.

I believe this model of giving (and the return karma) augurs well for society. There is room for a lot of hope and optimism.</comment></comment></comment>


All In: Now's The Time - <AUTHOR> http://techcrunch.com/2012/04/11/instagram-all-in/

<comment><USER2> So acquirers are going to pay too much for companies in the coming silly season and this should be your signal to really go "all in" on your startup?

Instagram hit the startup lottery. Awesome for them. But building a biz solely because of market frothiness and hoping to hit the lottery seems like a horribly misguided idea.

</comment><comment><USER3> <http://www.youtube.com/watch?v=I6IQ_FOCE6I>

Always appropriate. On a side note, really hard to know whether this is a bubble or not. I don't want to take either side, but you cannot refute that a billion dollars for a startup that did not gain any significant revenue seems like a lot of money.

</comment><comment><USER4> People get lucky. The instagram story was one of luck, rather than hard work (granted, they probably put in long hours but in the end they hit a goldmine purely on luck [plus I'm sure being connected to the top VCs & players in the valley didn't hurt]).

My point is, while it's great to encourage entrepreneurship, it's easier said than done.

<comment><USER5> Instagram is an exceptional product built with significant restraint and focus. It took them over a year and a half to release an Android app, because they were focused on what matters. This is exceedingly rare, as most teams would end up shortsightedly chasing the last few percent of users. Your assumption that the Instagram team has some above average connections in the valley is also baseless.

Make your own luck.

<comment><USER4> If you are going to say that my claims are baseless, please explain "... they focused on what matters.". What would that be exactly?

Significant restraint and focus? Please expand on what you also mean by this.

You're right on one point... They don't have above average connections. They have spectacular connections. Only the connections that being funded by Jack Dorsey, Sequoia, Benchmark, Andreessen Horowitz, etc. would provide.

<comment><USER5> What I mean is that typically these types of companies drive to support all platforms (including web), diluting their ability to execute. Instagram focused on excellent execution for a narrower user base and won over a large number of users. Considering the demand for an Android app, they held out for a very long time, until they were able to bring the same level of execution to that platform.

This isn't "connections." This is called an investment. It is because those investors realized the potential here and invested in the company. Maybe I read it wrong, but your post made it seem like there is some kind of unfair advantage they had because they "knew a guy who knew a guy." Only after they proved their ability to execute did they take significant funding and gain those connections.

</comment></comment></comment></comment><comment><USER6> _you need to slide all of your chips on to the table._

Is it a casino?

Thanks, but no thanks.

</comment><comment><USER7> I notice that the only use of "bubble" in the OP is when talking about the late 90s. Surely we want to move away from cash in while to goings good mentality the OP is promoting to something more sustainable. Otherwise we're going to see a further degradation of web technology as a good place to invest. I don't know if there is a bubble or not, but the language in the OP screams it.

This all assumes investors are capable of weighing up the relative merits of various investments and aren't blinded by big exits like that of Instagram. And the evidence continues to point to them being blinded by dollar signs . . .

</comment><comment><USER8> It's important to understand the context of this post. Adeo said it was an email to their startups which they decided to publish.

It's a pep talk to people who've already or are on the brink of taking the leap. In that light it's entirely applicable. It's not speaking against sane business models it's about use this as an opportunity to dig in and kick ass.

It doesn't matter how you get to "kick ass" ... as long as you get there.

</comment><comment><USER9> As an entrepreneur, what you really have to ask yourself is: are you pursuing your idea because you think you'll get rich, or because you want to change the world? Are you chasing money, or building value?

Valuations may be high right now, and some frothy transactions may be going on, but that doesn't make building a company any easier. If you can bootstrap, work on a project on the side, and keep a backup plan until you're ready to make the leap, do it! If the problem you're chasing is big and scary and capital intensive, then go raise the capital necessary to tackle it, but if not, you may be better off bootstrapping and building a 5 million dollar company you own all of than a 100 million dollar company where you end up heavily diluted [1].

[1] [http://www.gabrielweinberg.com/blog/2010/06/paths- to-5m-for-...](http://www.gabrielweinberg.com/blog/2010/06/paths-to-5m-for-a- startup-founder.html)

</comment><comment><USER10> If you're in your 20's and have skills now is the best time to do something big.

You're being squeezed on both sides. The gen-Xers that cashed out are reinvesting and flexing their muscles to win again. The teens and early twenty whippersnappers are hungry and foolish enough to think they'll win.

If you love what you do and do what you love then you'll win. Just make sure you love something worthwhile.

</comment><comment><USER11> Articles like this seem to me like a good sign that we might be entering bubble territory.

This is essentially saying, "hey everyone, time to cash in right now before the money dries up." Of course in that sentence "money" refers to capital, not revenues or profits. Such misplaced focus was the hallmark problem of the late 90's bubble.

I went in all-in for that bubble and got 10 months of hope followed by 4 months of COBRA and unemployment, then another regular ol' job.

</comment><comment><USER12> Yesterday Wired was saying that it's not a bubble.</comment>


Why Aren't Books Written More Like YouTube Mini Series? - <AUTHOR> http://pspeter3.github.com/blog/2012/04/12/why-arent-more-books-written-like-youtube-mini-series/

<comment><USER2> This is hardly a new idea. You could argue that many of Dickens's novels were written this way, bit-by-bit through installments in the newspaper. The format led to the cliffhanger nature of his stories.

Look at NaNoWriMo or DailyLit for current examples

<comment><AUTHOR> Thanks! I'm sure they existed, I just haven't seen a lot of it yet. Also, that is really cool about Dicken's</comment></comment>


Apply HN: Datalba – Your personal media search engine - <AUTHOR> Datalba's mission is to make sure all of your personally relevant media stays organized and searchable.
First and foremost: Knowing what matters to you. Datalba comes to know your preferences with a minimum of distraction. An occasional question or confirmation is enough to organize a mountain of data according to your tastes, and if you ever change your mind is easy for you let us know.
We make your images and videos searchable by content. You can search through your photo, article and video collection by who was involved, what was happening, where it was or when you were paying attention to it.
"What color was my birthday cake again?"
"Show me my little Sophie!"
"What happened last night?"
Have you ever been frustrated that you just can't seem to find that video again? No matter what you come up with to search for it it just won't come up for you.
You can save images and video that you find online or on services like Facebook in your collections, and retrieve them anytime with half-remembered descriptions.
"You know, that one movie… with the guy who had the hair, and that thing that happened with the car..."
Are you tired of spending so much time sorting through folders and sifting through links to manage that ever growing body of unmanaged things? You don't have to lose your stuff.
Typical search show undifferentiated piles of junk you've never seen or heard of. Why bother with that when you can pull up exactly what you need, what you care about.
Try Datalba: Your personal media search engine. <comment><USER2> I definitely find myself having to wade through my photo and video collection just to find that one that I remember I took a few years ago but for the life of me can't remember exactly when and where (which is the easiest way to sort and find). I think the key for me would be how much training/how many questions it would take for the search to become accurate. It would also be important to me to be able to use this offline. Don't fancy having to upload all my personal photos and videos.

Have you done any user testing yet?

I can imagine that if you get the algorithm to work robustly that there might actually be an entirely different, enterprise market.

Do you have a proprietary algorithm? Or are you using something well-known, published/publically available?

Would this simply be a product that the end user pays for? Or do you have another revenue stream in mind?

<comment><AUTHOR> I am very familiar with that process myself. :)

While a cached intermediate for offline use is a very real possibility, providing top quality service without use of our server system would not be feasible with the current device market. Server-side we can use hardware that is optimized for this kind of processing, without being constrained by device or browser limitations. Without that the service quality would degrade sufficiently to tarnish our product's image and turn people away.

One example of this is the one you provided: the quantity of training required for accurate answers. If we need to keep this metric tight, relying on random ARM processors and sandboxed single-threaded javascript is not the way.

Datalba's CEO is in the process of collecting early test users, and has been receiving large quantities of test media for use with the prototype from several of them.

Yes, there are many opportunities in the enterprise market for this. The immediate interest is in bringing a quality service to the world that many people will benefit from. The needs of enterprise customers are largely a subset of that goal, and the parts that aren't can be handled in a given contract or agreement.

We have been working with and building on the latest in deep learning research, and have become quite proficient with designing and building these technologies.

While we will undoubtably be exploring payed options, I fully expect that to make this product a real success that there needs to be as few barriers to access as possible for the user. Degrading accuracy based on a paywall, the most seemingly economical choice, would alienate the majority of users before they have a chance become highly engaged.

Additional value-adds such as auxiliary services could be monetized, but so far we have managed to collect a number of expressions from consumers that this leads to a very 'pushy' presentation. While more market data is needed, it is clear this is territory that should be tread lightly.

The remaining option that is most clear is to monetize in ways that don't directly make demands of our customers. It would be possible to produce very sophisticated market data from the information our service will collect, something that our partners are likely to find very valuable.

</comment></comment><comment><USER3> Well, this is awkward.

[http://remember.ai](http://remember.ai)

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

<comment><USER4> Looks like the same idea ha

<comment><AUTHOR> There is something of a resemblance, certainly. Nothing like a little healthy competition.

</comment></comment></comment><comment><USER5> Interesting idea but what about the privacy of the information? I wouldn't want my life to be in the hands of anyone else, all in one place, due to the risks involved.

<comment><AUTHOR> Customers who are not using our cloud storage service for storing content and who are concerned about security and privacy may have the option to have only metadata stored on our system. Once the images and other content have been processed the needed metadata has been largely collected, and can index remote storage. The media does need to be stored somewhere accessible to be searchable.

</comment></comment><comment><USER6> Datalba sounds like a fascinating idea! If it could run as a browser extension to tag media effortlessly, it would be immensely useful.

<comment><AUTHOR> A browser extension is planned, but only as one of several clients including a phone app and a website.

</comment></comment><comment><USER7> Google competitor

<comment><AUTHOR> Google is very unfocused. I've heard very a capable serial entrepreneur say "Google competes with everyone." I understand his consternation. But I certainly don't feel like Google has solved this problem for me when I'm fumbling around in Android Gallery.</comment></comment>


60 million stung in social networking rip-off - <AUTHOR> http://www.independent.co.uk/life-style/gadgets-and-tech/news/60-million-stung-in-social-networking-ripoff-1740647.html <comment><USER3> It's kinda funny to follow what's going on with Tagged.

About 2 years ago I had just accepted an offer with Scribd, but already had an interview set up with Tagged, so I decided to go to the interview just for the experience. I had initially declined the Tagged interview after looking at their site (asking myself "Would I ever use this?" and the answer was "Hell no"), but Greg Tseng called me and convinced me to change my mind. Man, that guy can talk - he's very smart and very persuasive. He told me about how they were already very profitable and about his team's expertise with "viral marketing" <cough>. So I decided to go and see what it was like.

I arrived at the interview in a lovely loft office downtown SF and met with the engineers who asked me to solve some low level complex computer science brain teasers. Having spent all of my previous 8 years building web systems for major universities and billion dollar companies and no time practicing computer science brain teasers, I failed pretty miserably ;)

Anyway, it obviously wasn't going to be a match, but it was an interesting life experience nonetheless. Fortunately working at Scribd was great - <USER2> great team and really interesting problems to solve.

</comment><comment><USER4> Tagged is a bottom feeder, but they they aren't really the worst of the worst. To some degree, I think having annoying, yet relatively harmless (They didn't install a keylogger, execute XSS against bank accounts, or format hard drives) companies like this in the Internet Ecosystem is a bit like vaccinating people against the truly dangerous diseases.

Over time, people will become a _little_ more savvy about clicking on these "Your friend just sent you X", be more alert to phishing, use slightly more secure and heterogeneous mail clients/browsers.

And then, when a truly dangerous black hat shows up, they won't have free reign over a completely unsuspecting populace.

<comment><USER5> I respect your faith in the general populace but I doubt that they'll become more savvy. Easy usage beats savvy computer practice on any day. Look at Facebook usage and the astounding amount of personal information that people reveal (especially the latest most tech savvy generation).

<comment><USER6> In my experience it's much less than it used to be--people sharing their AIM screen names, for instance, have almost universally stopped doing so, and physical addresses have disappeared too. Most people even lie about their relationship status.

</comment></comment></comment><comment><USER7> Tagged sucks, but the article omits the key fact that it only sent out emails to your contact list if you gave it access to your email account. It wasn't as simple as "Any click resulted in the same thing, Cuomo said: Every person on a user's contact list received an email".

Blaming only the company doesn't help people learn the appropriate lesson of "don't share your password."

<comment><USER8> While I agree with the idea that you should never share your password, you're blaming the victim. Having read a few accounts of their exploits now, this company is manipulating these people.

<comment><USER6> Some victims deserve blame. It's the rare con job that plays on our virtues and wisdom rather than our stupidity and baser desires.

<comment><USER9> So they deserve what they got for wanting to see pictures posted by their friends?

<comment><USER6> I don't think it rises to that level, but tedunangst and gojomo are both right in that imprudent user behavior was a necessary condition of this happening.

</comment></comment></comment></comment></comment><comment><USER10> Finally. The shady practices of Tagged are disgusting, I hope something actually comes out of this(a fine would be nice).

</comment><comment><USER11> Let's see: a social network using sleazy spamy user-acqusition techniques; a grandstanding state attorney general, and users who casually share their address books and mail logins with third party sites. Help! There's no one in this story to root for!

<comment><USER12> Maybe you don't hate spam as much as I do, but I'll root for the state attorney general.

</comment></comment><comment><USER13> Tagged Terms of Service:

"...Tagged reserves the right to modify or amend this Agreement at any time, for any reason, or for no reason at all, at Tagged's sole discretion. The most recent version of this Agreement will be posted on the Tagged website. Although Tagged will provide notice of material changes to this Agreement on the Tagged website, as a Member it is your sole responsibility to keep yourself apprised of any such modifications or amendments. Should Member object to any terms and conditions of the Agreement or any subsequent modifications thereto or become dissatisfied with Tagged in any way, Member's only recourse is to immediately: (1) discontinue use of Tagged; (2) terminate Tagged registration; and (3) notify Tagged of termination."

So, here're the terms but we can change them at any time for no reason at all and it's your responsibility to keep up.

<comment><USER14> Don't most terms of service have a clause in them similar to that?

</comment></comment><comment><USER15> I wonder how well their SQL scaled?

What? Too soon? ;)

</comment><comment><USER16> I wish there were some way to simply make it illegal to send emails to someone's contact list, no matter how many "yes, it's ok" check-boxes they click.

I lay some of the blame at the big-boys' feet (Facebook and friends) for getting users accustomed to this kind of behavior. Now people are so used to giving out their email credentials that they never stop to think that it's ALWAYS a bad idea.

</comment><comment><USER17> /me wonders what Terry Chay has to say about this...</comment>