dpezely

in 1996, we created the Seattle Peoples' Internet by co-locating our equipment at an upstart internet cafe in Belltown called Speakeasy.

The deal was that we paid for their most expensive monthly line item: the T1 circuit. We covered 100% of the T1 yet were allocated only 50% of the bandwidth, if I recall. We recruited enough co-op members to cover that fee before beginning and had a wait-list on Day One.

Our PortMaster was configured to monitor monthly bandwidth consumption per co-op member. We accommodated spikes in traffic of individual members, but if the aggregate went above some threshold, the co-op would pay more to Speakeasy. The intent here was that our overage fees would help pay for a second T1.

We also had some co-location hosts in their rack, which was around the corner from the coffee machine in those days.

Member fee schedule was proportional to type/speed of connection used and anticipated usage. Beyond that, membership was at cost.

Internally, co-op members would resolve financial details among ourselves, and we sent one payment check per month.

The agreement was fairly balanced. It allowed our members physical access to reboot a piece of co-located equipment, but any maintenance required pulling and removing the machine. (Again, rack was in tight quarters of a coffee shop.)

Since this was mid-1990's, all members supplied their own pair of modems for each side which were mostly 28.8 back then. I think one person was going with ISDN, and maybe another had Telebit Trailblazer 56k.

I'd like to think that upon seeing how this was a benefit to the cafe's financial statements that it gave Mike, Gretchen, Chris, et al the idea to move into the larger ISP space for which they then became known.

Usual disclaimers apply... speaking within US jurisdictions... based upon advice I received earlier in my career when asking the same question... and so on:

I created a personal website to which I would grant limited access to select portions and only to those potential employers for which I was actively considering. Not being public, there were no issues.

Alternatively, go old school and bring the copies with you on an interview. This might be hard copy screenshots, or connect your laptop to their projector during an interview such that you always retain control over the material. Then, if you can't click-through to a certain portion due to it being an unreleased feature, patent papers not yet filed, etc., you have the control to navigate to away from there.

As another person commented here, some content on my personal website were anonymized screenshots organized as a storyboard; others were full replications of the entire system's UI and server, complete with documentation and including the original company's name & logo.

Sometimes the intent to have a portfolio begins when you start the project.

Depending upon nature of your project, you may be able to create it in a way that easily accommodates an anonymous version.

For example with one particular project, I kept all of the corporate colors and logos within CSS of course but intentionally kept it isolated to a single style.css file to make it trivial to change. It was essentially a "white label" system to accommodate re-branding, co-branding, etc. (Of course, no potential employer was interested in an end-to-end recommender system with mix & match algorithms-- think: compiling regular expressions-- so I've never shown that one-- oh, the irony!)

Even if you are concerned about nondisclosures and noncompete agreements:

You can demonstrate what work you have done despite most wording within agreements because they cannot prevent you from continuing to work within your field or prohibit you from earning a living after providing labor/services under those agreement-- with a few obvious caveats.

Those caveats include explicit statements about specific items to which you have agreed, and even in some of those cases, you may still be OK based upon local laws. But you should know when you're in that situation and would of course talk to an attorney and/or your original employer.

"Recoverable system upgrades" - https://coreos.com/blog/recoverable-system-upgrades/

Run from root partition A and only update on partition B, essentially via chroot. Downtime required for updates is the cost of a reboot. If, however, upon an error during boot, reboot into other partition which will be your last known good config.

Seems simple and straight-forward but is difficult for unmodified Debian-based distributions, so they've addressed this as a key feature of CoreOS.

It's also worth calling attention to Lisp flavored Erlang (LFE), which has come a long way recently. They've specifically addressed language artifacts that would be more welcoming to someone coming from a strong Common Lisp background.

For seeing where it's heading, read Duncan's website: http://technicae.cogitat.io/search/label/lfe He gave an excellent presentation on this at Erlang Factory conference in San Francisco last month.

Otherwise, the main website is: http://lfe.github.io

There are instructions for using 'apt-get' and friends for installing current releases:

https://www.erlang-solutions.com/downloads/download-erlang-o...

While R17 wasn't ready for this approach immediately upon the announcement, I'd expect it any day since other pre-compiled packages have been made available already.

Essentially:

wget http://packages.erlang-solutions.com/erlang-solutions_1.0_al...

sudo dpkg -i erlang-solutions_1.0_all.deb

sudo apt-get update

sudo apt-get install erlang

I get continually reminded of this when people see that I registered play.org as late as mid-1994. It was still free, and a substantial number of English words were still available. I'm often reminded by others that I could have also registered play.com or other common words.

Of course, much of the culture back then was: I only need one domain. This one was for my personal site, so obviously, it shouldn't be .com domain...

No regrets, though: I wouldn't want to be the type of person that looks for "under-utilized resources" to exploit. There are far more interesting things in life than that for me.

For the near-1kg range: Samsung Series 9 (NP900X3C-A01US)

Ubuntu 12.04.1 installs & runs without modification, but some minor Fn keys didn't work (e.g., WiFi toggle button).

Arch Linux with systemd installs & runs fine, and it had great battery life because 'rfkill block all' seems to more thoroughly power-down those circuits on Arch than Ubuntu. (well over 7 hours with wired ethernet, plus Emacs and Firefox in heavy use)

Chris Esposito at Boeing in the early 1990's worked on such a project: aircraft maintenance augmented using "VR glasses" concurrently developed at the Human Interface Technology Lab in Seattle.

I suspect that this is his profile: http://www.linkedin.com/pub/chris-esposito/5/673/785

Although Google will make this more popular due to their marketing efforts and brand, it's hardly their brainchild.

Tom Furness developed similar devices decades ago: Once out of the military lab, this was a key project of the Human Interface Technology Lab at UW in Seattle in the early 1990's.

Updating for smaller chips and components contributes to the current form-factor which includes the front-facing camera not present in the earliest versions.

The upside of course is that this might finally get some traction with Google's budget and efforts.

Yes, end results are equivalent, but complexity shifts.

If a consistent stack is more important, caching may be the best option. If fewer layers of complexity at run-time is more important, out-of-band/pre-processing may be the best option.

Serving static files is more about pre-processing, or rather:

Don't do at run-time what can be done at compile-time.

This doesn't need to be any more manual that the labor involved in uploading content into a CMS or data store by another name (e.g., blog engine). It's more of a substitution of one task for another.

I prefer to think of the static HTML approach as the difference between using Makefiles versus a shell script for compiling code. Once you understand that the shell script will duplicate nuances that 'make' offers, use of Makefiles for compiling code usually gets viewed as the better approach. (There are always edge-cases, of course.)

There's a conference this week in San Francisco that is to cover these topics: http://SentimentSymposium.com

Why change machines when at your desk versus elsewhere? That sounds like an 'rsync' accident waiting to happen.

I've been using the first generation 11.6" Air which replaced a unibody 15". Other than FreeBSD and Linux servers racked elsewhere, this Air is my "everything" machine.

My tricks for the smaller screen:

Keep windows overlapping with just enough visible underneath to indicate status, and of course set the Dock to auto-hide. e.g., Mail window is on far right with little more than the scroll bar showing, so I can still see whether the horizontal cursor/bar is at bottom of that window or not, which indicates new mail. Of course, when I'm deep into code-mode, I don't want the distraction of email anyway until I come up to breathe, so it's one less distraction.

Likewise for Terminal. I have less than one row of text visible underneath Emacs, VMware and browsers. This is just enough to see if a background compilation or other task is still running. Again, like email-- one less distraction unless and until I want to be aware of it.

In Emacs, I'm using my own build of 24.0.50 with 185x46 character resolution and make heavy use of 'split-window-horizontally instead of 'split-window-vertically which I used predominantly on earlier machines since 1989.

> I really surprised at Google by this implementation--it seems like they didn't really think it through.

You're looking for utility; whereas, I believe they are taking a pro-active step against Facebook's newly awarded patents on "social search."

Regarding utility: it's Google, so they'll iterate...

Regarding competition: it's launched and available to the public now!

When Facebook acquired Friendster.com, this also gave control over lucrative patents that were awarded this year and last year.

http://news.ycombinator.com/item?id=2351407

I have a current model 11.6" Air purchased in January, and Xcode was pre-installed into /Developer.

This was a stock machine: walked into Apple Store to buy it. (No special factory config)

Compiling SBCL and a few items from MacPorts worked fine, so everything seems consistent with what I've seen on other Macs since 2005.

Continuing your first point that the industry is fairly young:

We also have a "mythology effect" but with a twist... It applies to companies alive and thriving today (unlike an urban myth where no credible source can be found).

Consider stories from early days at Apple and other companies where no one was older than 30, then 35, then they stopped reporting. That was mid-1980's and into early 1990's for other businesses. Then it repeated in 1999-2000 with brand name dot com start-ups. It's happening today with upstart game companies that consider 7 years experience to be senior level.

So this meme persists on some level with each wave of newcomers (e.g., college grads).

I suspect that the effect gets compounded by newer programmers beginning with relatively newer languages and tools. It's easier to master a language/tool when it grows up with you. I saw this when C became mainstream, with Python, with Ruby, and currently with Clojure, Scala, etc.

When C was blossoming outside of Bell Labs (following Peter Norton's "Industrial Strength Programming Language" article in mid-1980's), when Python was merely v1.5 in 1999, when Ruby wasn't yet associated with Rails-- the majority of people using these were young, looking for an edge and seeking to avoid pitfalls associated with urban myths about what came before. (e.g., pre-ANSI C satisfied concerns that Lisp was slow and required special hardware-- myths circulating college labs of late 1980's)

It's easier to debunk these things today, thanks to the programming languages shoot-out, stackoverflow and threaded comments such as on HN. Due to these reality-check possibilities, we may hopefully put such systemic ignorance behind us.

Related: solicited by internal Google recruiter but declined.

Google sucked-up nearly all the Python people from Seattle mid-decade this way, just as I was migrating back to Common Lisp, so it wasn't that appealing to me anyway.

It was months before the IPO was announced, no bus from SF yet, no SF office then, and I couldn't bear a reverse-commute. (Wife doesn't drive, so living outside the city not an option)

The bit regarding the winner getting to make a new rule has long been tested since the industrial revolution and likely far before then: In that context, of course, the new "rule" is essentially a law through lobby efforts, etc.

It becomes a competitive advantage to win early for express purpose of introducing protectionist mechanisms that would favor your particular technique or more likely, blocking the approach used by one's greatest challenger.

This may degenerate to "dirty tricks" early for the sake of an early win.

Therefore, to counteract that tendency:

Consider an "evolving" world. Take a card from artificial life techniques or randomly permute some attribute of the environment; e.g., terrain might become a more rocky, introduction of a natural predator, or perhaps switch from land to sea.

Mythology is rich with scenarios to draw upon.

I'd recommend NOT revealing the change until the round begins! Between rounds, let participants experiment only with the previous iteration of the world.

The jargon file's "tape" reference is likely to mean paper-tape than magnetic 9-track, so the term possibly goes back further to card-punch days. (I first heard the term in 1985 at my first job during high school: a PC consulting shop.)

I'd hazard a guess that the term was lifted from Navy or other such source far predating movement of electronic bits.

Anyone?

Sony's Y Series uses the ultra-low voltage version of Core2 Duo, consuming about 10W with a 13" LCD. No internal disc, but Ubuntu and FreeBSD are easily installed via USB stick...

Unfortunately, Sony Y Series inventory has been depleted, so it's not listed on the US sonystyle website today. A chat with their sales rep indicated that the product line will return soon. Other series also seem to have limited inventory, so a full product line refresh seems due soon!

However, after reading other people's concerns (above) regarding Linux drivers and VT disabled, I'm reconsidering. A friend has the current F series (i7) running Linux just fine, btw.

I've used Hunchentoot (weitz.de/hunchentoot) in production with strong track record.

antiweb (hoytech.com/antiweb) also looks promising, but I haven't put anything into production with it yet.

What are your criteria for analytics?

If you require third-party reporting for vetting your traffic numbers to potential advertisers, there are services such as Quantcast.com.

The big fish in the game is Omniture.com, recently acquired by Adobe. It's worth looking at their documentation because they have become (arguably) the de facto standard in many areas of web analytics, particularly marketing analytics for websites. Knowing their jargon and how they bucket data can be useful in those conversations.

Many people want free as in zero out-of-pocket expense and freedom to customize. More on that below...

The trade-off with completely free techniques is that you lose any demographic or psychographic profiling that a larger service provider might offer. If this subject matters to you, BlueKai.com would be a good starting point, but be prepared to talk about marketing "funnels". (Not sure if they accommodate beyond US, though.)

For leveraging this class of data, real-time ad networks such as Adchemy.com use these technique to drive traffic. They'll likely be expanding beyond US soon. [full disclosure: my current employer is a partner of theirs]

Back to free:

If you simply want to know basic facts about traffic landing on your pages and considering the HN crowd, you could likely get by with a little JavaScript code that generates a URL with query-strings identifying those facts. Then use JS to insert an image into the page, fetching a 1x1 transparent pixel from your own server, thereby logging the facts. Various tools for analyzing HTTP logs are available for bucketing, graphing, etc.

The Nginx HTTP server has native support for serving transparent pixels and has a very light load (e.g., an Intel Atom CPU on your DSL line is more than adequate; under US$200 complete). Since it's all under your control, this approach can still work with dynamic IP addressing of the pixel server.

Some relevant JS fields and function calls include: navigator.cookieEnabled, screen.height, screen.width, screen.colorDepth, navigator.plugins['Shockwave Flash'], window.ActiveXObject() with "ShockwaveFlash.ShockwaveFlash" [but search for caveats regarding known bugs with Flash 6.0.21, .23, .29].

Add your own session ID to the query-string, and you have unique visitor journey tracking as well. Usual caveats apply due to visitors who clear cookies, etc.

Again, considering the HN crowd, this minimal treatment should be sufficient.

Regarding a return of Linda, I couldn't help but note similar themes when first learning about Amazon's Dynamo and later, the Apache Cassandra Project. I'm not saying that there's a perfect match, but when one's imagination has academic roots in the era of Linda, it was easy to see a connection through that lens.

Anyone else see the potential there?

At the very least, it influences how I might use something like Cassandra (or dbm files for that matter), and I've been planting the meme for others to approach their designs that way too.

It may be worth noting that developers don't necessarily need official apps for everything. That is, github becomes an implicit app store because we can build locally and push to our own devices.

I suspect this to be the only means by which Emacs will become available on iPhoneOS, for instance. Considering the intended user base, that's acceptable as a starting place.

(To preempt certain class of questions: Use the "happy hacker"/"das keyboard" concept by implementing an unmarked keyboard underneath a partially transparent background, so you maximize text on screen while also accommodating typing without external keyboard. For Emacs in particular, just hit C-l or otherwise scroll when cursor lands beneath fingers. That's one step closer to YCRFS5...)

I would emphasize that the killer app for Lisp is simply programming. "Simply" in the sense that you're unencumbered and not fenced in to any particular cliche such as Ruby being stereotyped in its association with Rails.

Ten years ago when deep into Python, I'd explain the language to others by including the disclaimer that you probably wouldn't want to use it for writing an OS. Writing a near-deterministic scheduler in it ultimately motivated my return to Lisp.

I offer no such disclaimer when describing Common Lisp to other programmers, executives or founders at start-ups where I've used it.

Apparently, most people want to convince themselves of the value for a tool by citing something external. To this end, it's likely that the success of EVE Online has helped Stackless/Python in terms of reputation.

I suspect everyone paid to write Lisp that I know would respond with something like: if you need that kind of external validation, then you probably don't know what you really need or want, so let's not wake the sleepwalker.

Maybe the sociological question has to do with why some people need/want that validation (killer app) versus those who don't.

For completeness and to preempt questions of what is the EVE equivalent for Lisp success stories: early days of NaughtyDog using GOAL, work at the University of Colorado and 2010 book, _Land of Lisp_, just to name a few.

But that will never be enough for people who prefer commodity languages for the sake of safety in numbers, as Lisp isn't commodity today. More than just a bootstrapping issue or citing decline due to the AI winter, it may never reach critical mass to be commodity because so few individuals are involved with each success story.

That is, since you often need only a few developers when using Lisp, there's less need to evangelize when recruiting. Job postings I've made have often been a single sentence mentioning Common Lisp and the city, which yielded very high quality people.

It's rather like what is said of big dogs: they don't bark nearly as much as little ones because there's nothing to prove.

For Lisp, questions of killer apps and becoming a mainstream or commodity language (again) is unfortunately impacted by this larger context. Certainly, I would love to see my favorite language enjoying popular status. In the end, however, it's rather like some explanations for the meaning of life: it's a personal quest, and the journey is part of the answer. So too with deciding to use Lisp. It's okay to break-away from the crowd.

This brings us back to one recurring theme of Justin's essays: Try it and decide for yourself. Or Don't.

Regarding "aversion to math," many developers unfortunately opt for the least they can get away with and retain only enough to pass exams or interview questions. It's the difference between being able to recite versus being resourceful and the array of implications associated with each. I suspect that statement is aimed at people who became programmers because it pays better than other directions the individual has considered.