The Right Way to Accept a Job Offer - <AUTHOR> https://designerfund.com/bridge/right-way-accept-job-offer/ <comment><USER2> "only to find after 6 months that the job isn't what they expected."

Far too many times, even after discussing the role at length. It's nothing like was discussed. Then after starting, I want to start looking immediately.

If you're not pinched for a job, where you need it now. Because of life. Then:

* Don't be afraid to negotiate. If they say no to a minor bump. What does that say about your raise at the yearly review? An approach I've taken is a 90-day review. If I've not exceeded your expectations, then I have something to get better at. But more often than not I get that minor bump.

* Hash out career growth, if you want. There is nothing wrong with coming in and doing your job. But if you want to grow, make sure you have the platform to do so. Be specific, technology, languages, processes. See if they're open to you grabbing the ball and running with something.

* Ask additional questions about internal processes. Agile, development, etc. This has been one of my bigger qualms when I end up joining.

* If you care about this. When was the last time the office layout was changed? What were the improvements made? This hones in on making a larger bullpen style.

* Does it line up with your technical development flow. If you've gotten used to blazing through something in a specific team setting. It can be quite jarring to pull a 360.

* Do they provide the tools for you to work at your best? I'm not one for the latest laptop, etc. But do you get admin rights on your laptop? Can you install the software you need to work? Does the way they develop enable or hinder you, etc.

* etc.

We spend a large chunk of our times at our jobs. If it's something we dislike, or at worst hate. It can really detract from our quality of life. A good company should be willing to talk with you about your concerns. I'd almost think they'd be happy you care to dig in and get to know your workplace. Because they want you to be happy. Because as noted it's expensive to interview, hire, then retrain someone.

<comment><USER3> Contract to Perm was always a definite "no" for me before. I viewed it as too risky. But since getting married and my spouse having benefits, I've done it twice - with opposite outcomes and I'm starting to like the trial period. I think it's a win win.

The first time was back in 2012. I was laid off from my job after the company I was working for was acquired for the customer base. I needed a job fast, and they were using the technology stack I was trying to transistion to. I didn't have the network I have now.

It was the worse experience ever. I went in to talk to the manager about me turning in my resignation because it wasn't working out, I wasn't really able to contribute, and I wanted to look for a job full time. He said just to stick around until I found something. I couldn't. I called my recruiter, and had a job offer four days later at what was then a Fortune 10 company.

If I had had a permanent job, I probably wouldn't have just walked out.

A few years later I was applying for my current job as a dev lead. It was a W2 Contract to Perm (W2 means you are an employee of the agency and they pay employment taxes). The hourly rate was well below what I wanted and the conversion rate they submitted me at was below market. I took the contract anyway because I hit it off with my now manager and felt I would be in a much better negotiating position in 6 months if I went permanent.

The way I saw it, we were taking a chance on each other. It was my first lead position so he was taking a chance on me and the department that I was leading wasn't set up for modern development. I was taking a chance that the company would support me coming in and basically recreating the department.

While contracting, all the work that needed to be done couldn't be done in a 40 hour work week. I got paid for every hour I worked and got results. When it was time to go perm, I had a proven track record and the company had evidence that I knew what I was doing. I was able to negotiate a much higher pay than I could have when I first started and received a promotion.

</comment></comment><comment><USER4> "Every now and then, I see a designer who's over the moon to sign with a company, only to find after 6 months that the job isn't what they expected."

Ironically, looking at the Twitter bio of the author, it looks like she has moved on from her job at Designer Fund

</comment><comment><USER5> At which point is it acceptable or preferable to receive the draft of the employment contract? When receiving the job offer? After accepting the job offer? On the day employment contract is signed?

<comment><USER6> This depends on the country. In France you would typically get the contract (not a draft) before signing.</comment></comment>


My Favorite Thing About the iPad: No Writing/Logo/Other Crap on the Bezel - <AUTHOR> http://www.41latitude.com/post/504200201/no-logo <comment><USER2> When I first saw the iPad demo, I thought the wide black bezel looked too thick - like; why couldn't they shrink it down some?

I had a chance to play with a coworker's iPad today and I realized the bezel is that thick by design - it's where your fingers go when you're holding the device. It really is well designed.

</comment><comment><USER3> I LOVE this idea, I've always detested unnecessary and ugly branding that only serves to detract from the aesthetics of the product.

<comment><USER4> HBO does this on some of their channels. The lack of any branding makes it look more premium in my opinion.

<comment><USER5> I wish clothing designers would do this, too. I like nice clothes, but I absolutely cannot stand any branding.

(I am specifically referring to "designer" jeans. All the jeans made of decent fabric seem to have retarded-looking designer-specific branding on them. For other stuff, American Apparel has treated me rather well.)

<comment><USER6> There's a simple solution for that, strip the brands off after buying. I do that to all of the stuff I have with brands on it as far as it is feasible, best make sure it really fits before you do that though!

I'm not a billboard, and I refuse to have companies stamp their brands on me.

A little tool like this:

[http://www.fourniturenparadijs.nl/components/com_virtuemart/...](http://www.fourniturenparadijs.nl/components/com_virtuemart/shop_image/product/690aceb3c18ae9e61e3748205b2b6d5a.jpg)

Is all you need, it takes just a few minutes and unless they factory has been nasty it won't leave any visible traces.

<comment><USER7> "Branding is for cattle", is what I say about it. I also rip out the externals, if for some reason I even buy the stuff with it. I'm OK with the traditional maker's labels inside suit jackets, etc.

In older times, a person's monogram would be on handkerchiefs, shirts, bedsheets, etc. (I guess it was helpful as a laundry mark). Replacing that with the sellers brand is distasteful.

</comment></comment></comment></comment></comment><comment><USER8> Not related at all but I find it amusing you can look at the iPad and determine by the screen smudges what task it's been used for recently. Horizontal lines on the right side? You've been reading a book. I'm wondering if anyone else has noticed that on a glossy touchscreen, over time, some magical process happens (filth build up? chemical reaction?) where smudges just aren't very noticeable anymore. My iPhone 3G screen for example looks smudge free but I know if I give it a good cleaning it's really filthy. My theory is a base coat of filth builds up which is actually a good smudge repellent.

</comment><comment><USER9> along similar lines, one of my favourite things about the iphone is the lack of carrier branding. i can only speak for australia, but carriers over here like to stick their logos all over the phone itself and re-brand the software interface also. it creates a horrible ugly mess.

</comment><comment><USER10> This is also noticeable on all the other Apple products, especially laptops. I really disliked getting a top of the line Thinkpad from my old company and having those cheap Intel/Windows stickers.

</comment><comment><USER11> "Let's hope the iPad starts a trend."

Like maybe not branding half our pants, most of our shirts, and every single damn thing they sell us for kids to wear, eat, or play with? That'd be nice.

</comment><comment><USER5> The indented home button is the logo.

</comment><comment><USER5> Also note how Netflix is so obsessed with branding that the movie isn't even full-screen; their logo takes up a third of it!

<comment><USER12> <http://imgur.com/wrDDC.png>

There is no Netflix logo present in either portrait or landscape mode, whilst a movie is playing.

</comment></comment><comment><USER13> When the user experience is the branding, you don't need anything else.

</comment><comment><USER14> How is this different from the iPod Touch and iPhones?

<comment><AUTHOR> It's not.

But it is different from the HP slate: [http://h20435.www2.hp.com/t5/Voodoo- Blog/HP-s-Slate-Device-D...](http://h20435.www2.hp.com/t5/Voodoo-Blog/HP-s- Slate-Device-Delivers-a-Holistic-Mobile-Experience/ba-p/54735)

</comment></comment><comment><USER15> I don't think having a logo in the front is a big deal. My laptop, monitors, and tv's have logos on them and honestly it doesn't distract me at all, probably because the screens are bright or maybe I've just become accustomed to them.

</comment><comment><USER16> My least favorite thing about the official Apple iPad case: the Apple logo on the front.

(I'd prefer it look like a cheap pad of paper; less worries about leaving it on a table or passenger seat.)

<comment><USER17> Personally I want one that says _Don't Panic_.

<comment><USER18> We can take care of both your wish and gojomo's complaint with _stickers_!</comment></comment></comment>


11/13/17 19:23:29 tonight consists of adjacent, increasing primes - <AUTHOR> Tonight at 11/13/17 19:23:29  six adjacent prime numbers are in ascending order. I think, we won't get this pattern again in the lifetime of our universe. <comment><USER2> We get that every century.

Also, there is 2/3/5 7:09:11 and similar.

</comment><comment><USER3> interesting observation :)

</comment><comment><USER4> cool</comment>


Git vs. Mercurial: Please Relax - <AUTHOR> http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

<comment><USER2> I loved this article. That being said:

 _This brings us to another of git's faults: its documentation is terrible. Man pages are no longer a sufficient replacement for a good, well-updated wiki or reference work;_

Huh? This is the kind of thing that IT pedants say when they don't have any better arguments. There's absolutely nothing wrong with a good man page (or, to be sure, any documentation format at all). /usr/bin/man, in 2008, is still my first choice for looking up the interface to system calls, C APIs and command line utilities like git.

Now, could some of git's man pages use some work? Sure. But make that the criticism. Smacking about the format is just dumb.

<comment><USER3> ...What if there was a wiki that people could use to participate in the documentation, and then that documentation would become the man page with the next release? Everyone wins?

I like and use both man pages and wikis, but I'm not sure how I would even begin to participate in helping with documentation for something like a man page if I wanted to. The actual creation of the man page itself, as I understand it, is a single-user task. If you want community involvement to get source material, you're going to have to have an accessible participatory mechanism; a wiki, essentially, in whatever form that may take. But it should be easy, no?

I suppose there's also the counter argument that "people who need wikis to participate in something like git documentation are probably not the people we want writing git documentation."

<comment><USER4> <http://book.git-scm.com/>

<comment><USER3> Boom! That's a great site. Thanks for sharing.

</comment></comment></comment></comment><comment><USER5> All this hg vs git, but no one remembers monotone (which had some influence on git's development)

www.monotone.ca

Its a single file binary

Its supported on windows, linux, solaris and mac

has an interface for both scripts and users

Great documentation (and an easy to follow tutorial)

Interface is Stable

Single file to store the repo. I enjoy this b/c it makes backups extremely easy.

Negatives are:

It may not be as fast as Git, but the difference is barely noticeable.

Pulling an initial repo from the master is slow when there are tens of thousands of commits in the tree. After the initial pull, sync's between repos are quick.

Diffs in MS Windows takes substantially longer than in linux.

Monotone may not be a perfect choice for the linux kernel, but its a great DVS that's easy to use, stable and lets linux/mac/windows guys work together.

<comment><USER6> And if you enable inode caching, it's _substantially_ faster. I wonder why this isn't a default -- it seems like it is for hg and git, but people miss the option in mtn and write it off as being slow.

</comment></comment><comment><USER7> Summary: neither is ready yet. Wait for one to get good enough to make the other unnecessary.

My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?

Ok, that question wasn't rhetorical, I'm curious.

<comment><USER8> I'd say they're both ready, and I've used them both for over a year now with no problems.

 _My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?_

I prefer hg for just this reason. But unfortunately, it looks like git is going to win. Why? <http://github.com>. Fortunately, they're both pretty good, and so living with git isn't the end of the world.

<comment><USER9> I agree that it looks like git is going to win, but for entirely different reasons:

1) The person who wrote it is famous. It wouldn't have been taken seriously had (almost) anyone else written something comparable.

2) Network effects apply strongly here. You can't just use something else if you want to collaborate with people who use it.

I'm not very happy about having to use git, but the pain numbs after a while. And, to be fair, it does have some cool features, although little-to-nothing inherent to git or its implementation.

</comment></comment></comment><comment><USER10> _As such, the git project has consciously made no effort to make the migration to git easy: the revert command in Subversion resets your current working copy to the last commit, but in git undoes a supplied patch and commits the changes needed to remove that patch. (The equivalent command for svn revert in git is git reset --hard HEAD^.)_

Yes. You can't just make shit up and expect the computer to understand what you mean. Last time I checked, git came with extensive documentation. Try reading it :P

Anyway, I think hg takes the right approach to design -- a library that some shell scripts call into. Git takes a non-ideal approach -- monolithic scripts all written in different languages that sometimes share nothing. (Or more often, call each other to "abstract away" some details.)

But despite this, git is much nicer to use. It's more flexible, more consistent, and has a lot of really nice sugar. But I guess if you think svn is the only way revision control can work, you won't like it. Your loss. <link to "Beating the Averages">.

</comment><comment><USER11> mercurial is one binary you say? well hg is basically just this:

from mercurial import demandimport; demandimport.enable()

import sys import mercurial.util import mercurial.dispatch

for fp in (sys.stdin, sys.stdout, sys.stderr): mercurial.util.set_binary(fp)

mercurial.dispatch.run()

....

that is a front end for this: ancestor.py demandimport.py hook.py mail.py simplemerge.py util.py archival.py dirstate.py httprangereader.py manifest.py sshrepo.py util_win32.py bundlerepo.py dispatch.py httprepo.py mdiff.py sshserver.py verify.py byterange.py extensions.py i18n.py merge.py statichttprepo.py __version__.py changegroup.py fancyopts.py ignore.py node.py streamclone.py version.py changelog.py filelog.py __init__.py osutil.py strutil.py cmdutil.py filemerge.py keepalive.py patch.py templatefilters.py commands.py hbisect.py localrepo.py repair.py templater.py context.py help.py lock.py repo.py transaction.py copies.py hg.py lsprof.py revlog.py ui.py

so what are you talking about?

<comment><USER6> Apples to oranges. That's comparable to listing every source file in git.

How many of those do you ever execute directly? (How many are even in your shell execution path?) All of the interaction with it is namespaced behind the hg executable, including extensions.

<comment><USER11> what's the difference?

hg status -someflag | xargs do-something

git-status -someflag | xargs do-something

as far as usage is concerned -- is hg really less tool like? you're right, it is partly semantics. however the article over-simplifies things to the point of being misleading.

<comment><USER6> One semantic/aesthetic difference is that git floods tab completion with all the git- items, which is needlessly annoying. Namespacing the entire public interface behind one executable feels cleaner.

I suspect the underlying reason people complain about this is that it's a particularly visible instance of hg having a vastly cleaner public interface than git. Of course, one person's "feeling cleaner" is another person's "easier to write scripts/extensions for that won't break every time the public interface to the relevant exposed internals change in the slightest way". There seems to be much less effort to encapsulate the git interface for consistent external usage.*

Some people will prefer git for just this reason, though: You can easily get at the internals, if necessary. Like most of these "holy wars", it's a trade- off, and different people have different values. Make an informed decision. (Git's design values seem to resemble C's, while hg more closely fits Python's. I strongly prefer the latter.)

* This is unsurprising, though: Linus has spoken rather condescendingly of monotone's "nice object-oriented libraries". (<http://lwn.net/Articles/249460/>) (He also complained that it was slow, though he caught it at a particularly bad time -- one of the lead developers had just gone on sabbatical (and was preparing to move across the country), and the issues causing the sluggishness were fixed shortly after.)

<comment><USER11> git is pretty good at dealing with lots of local branches. it has git-stash which supports that even further (stash it now, come back to it later). it has a staging area which allows you to slice and dice your commits. it seems to be better and allowing you to rewrite the commit history.

i don't like git-repack, git-gc. i prefer the hg revlog approach.

hg can package all of its state from a given commit into what they call bundles. git only has git-format. can git-format be as self-describing as a bundle?

you can't delete named branches from mercurial. i say, so what. we have an inactive branch. we merge uninteresting branches into there. hg branches -a then shows you the unmerged (active) branches.

they're both good. it mostly depends on the way you and your team work.

<comment><USER6> Agreed. I prefer hg overall, but I know it's more due to style than a clear technical advantage one way or the other.

Is it possible to set branches -a to be the default in your hgrc, by the way? (I was going to check on that this weekend.)

<comment><USER11> i don't think so no. you may have to go with a wrapper script or an alias.

do you know if it's possible to do bundles in git?

<comment><USER6> Haven't tried, sorry.

It looks like you can add

      [defaults]
      branches = -a

to your hgrc to ignore inactive branches by default, though.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Instead of arguing for one over the other, how about volunteering your time and skills toward improving your favorite's weak areas? They're both quite good, but there's always room for improvement. Give something back!

For example, if I have time this weekend, I'm going to work on adding support for hg's record extension to its (already quite good, IMHO) Emacs interface.

</comment><comment><USER12> Feels like a bike shed to me. The other %99 of the world is still using cvs or subversion or something else, waiting to see what proves stable over a number of years. Companies are going to thrive or fail depending on the products they create, not the version control system they use.

<comment><USER13> I could be doing a lot more creating at my company if I wasn't shackled to our out-of-date version control system.

This is actually a serious issue which is finally getting traction to fix at the management level.

<comment><USER12> > This is actually a serious issue which is finally getting traction to fix at > the management level.

I'm guessing that 'version control' is just one symptom of other underlying problems. I just don't buy that you're not creating a good product because of version control.

<comment><USER13> Oh, there are absolutely other problems. I'm not trying to pin all the problems on CVS. It's just a major pain point which can actually be addressed with a technological, rather than a cultural, solution.

The root problem is probably extreme conservatism coupled with an unwillingness or inability to sensibly delegate responsibility, which adds up to systemic paralysis when it comes to actually getting things done. It is not a Hacker-friendly place. I'm fortunate enough to be in a small team which manages to bypass a lot of the mess, but I'm still not sure how long I actually want to stay here.

</comment></comment></comment></comment><comment><USER14> _Despite that glaring flaw, the rest of hg is excellent. It functions almost identically to Subversion in the commands that it shares, and the new concepts - branching, merging, etc._

why exactly does the author refer to branching/merging as new concepts?</comment>


Query StackOverflow (Stack Exchange Data Explorer) - <AUTHOR> http://data.stackexchange.com/stackoverflow/queries

<comment><USER2> What is even cooler, is the fact that SE have open sourced the code! <http://code.google.com/p/stack-exchange-data-explorer/>

</comment><comment><USER3> My favourite - Jon Skeet comparison - [http://data.stackexchange.com/stackoverflow/query/3160/jon-s...](http://data.stackexchange.com/stackoverflow/query/3160/jon- skeet-comparison)</comment>


Google Play Music adds podcasts with machine learning recommendations - <AUTHOR> http://officialandroid.blogspot.com/2016/04/welcome-to-google-play-music-podcast.html <comment><AUTHOR> Apple added podcasts support to iTunes in 2005.

Google started onboarding publishers for this rollout in October 2015

Does anyone know what took Google so long?</comment>


The Suburbs Are Coming to a City Near You - <AUTHOR> https://www.nytimes.com/2019/05/18/opinion/sunday/the-suburbs-cities.html <comment><USER2> TLDR: the upper middle class is moving from the suburbs to the city, so real estate developers are catering to them by offering more amenities.

The article then delves into the specifics of what these amenities are. I don't see the point, honestly.</comment>


Who You Gonna Call, The Intenet Police? - <AUTHOR> http://tweetagewasteland.com/2011/04/calling-the-internet-police/

<comment><USER2> " _After Hudson rightfully said no, the engineer responded by hijacking the site, right down to the domain name. And he did a pretty good job of it. No one could help. Other engineers didn't have the required credentials. His hosting provider had no means to solve the problem. And even GoDaddy (where he registered the domain) couldn't figure out a good way around the hack that the engineer had devised to hold the site and its contents hostage._ "

It's strange to me that the registrar would acknowledge that a takeover had happened but wouldn't be able to fix it, unless the domains were transferred to another registrar. The article doesn't give any details, but if that's the case, the lesson there is not to give other people access to your account at that level (GoDaddy provides a feature to prevent exactly that situation: <http://www.godaddy.com/account/accountexec.aspx>).

<comment><USER3> We must have to assume the developers registered the domain for the client and it was in their name and the client had no way of actually proving that the domain belonged to them - probably because it was an obscure name, and not the name of their company.

<comment><USER4> So, essentially, incompetence mixed with blackmail. Can't really blame technology for that.

(edit: I think there's a big part of the story we're missing here. Seriously, what company that claims to be a "new and promising internet business" outsources its _engineering_?)

</comment></comment></comment><comment><USER4> ok, I've read this over twice, and I'll bite - how was this "hijack"/"hack" done? I think it'll be helpful for us to know this so we can try to avoid it in the future.

<comment><USER3> I had the same problem. It was hard to continue reading when I was "stuck" back in the "hijack" paragraph.

All I can figure is that the consultants were the ones who purchased the domain and it was in their name. They built and hosted the site, and could change all passwords to everything. The service being built must have had an obscure name, not the official name of the company that had hired the contractors to build it so they couldn't even fax in identifying documents to GoDaddy to show claim to the domain and that it was their company.</comment></comment>


San Francisco bans parking space apps - <AUTHOR> http://www.bbc.com/news/technology-27995429 <comment><USER2> Well, duh ! They have an app that auctions the public parking space you are currently in - and you wait in it till the buyer arrives

How did anyone expect that would remain ethical or legal?

There are many ways technology could improve parking in SF but making private profits off public resources is not it.

<comment><USER3> Nature finds a way. The free market is the little green shoots growing up between the cracks of the grey statist utopian paved earth. Technology is allowing innovators to outpace the entitled dullards that inhabit the halls of political privilege. They'll shut this down, with all you fine citizens celebrating, but the innovators will route around it again.

<comment><USER2> People making money out of someone else's property is what this app and airbnb _do_. That's not a clever hack or capitalism finding a way - that's stealing and hoping no one notices.

Regulation at its core is a vital part of a free market (and by the way the only free part we really care about is freedom to set a price)

We regulate murder, kidnap, extortion and parking bye-laws. We do that so we can all move forward in a society packed full of other selfish Great Apes with weapons.

It works - we are living proof. It can always be improved, but almost always a market failure in the western world is down to some greedy bastard somewhere breaking the rules to obtain an advantage and not getting shutdown fast enough.

<comment><USER4> airbnb makes money off private property and I cannot possibly see how renting your own house to someone would be called stealing. This app makes money of public property, and that is where the difference is - it's as if you were auctioning off your place in a homeless shelter, if you want to stick to the AirBnB reference.

<comment><USER2> A "large proportion" of airbnb is sub-letting - either a flat for a week while away, a room for months or other types banned in the original lease contract. Even some people who own their own leasehold in the uk don't have rental rights.

The BBC estimated that was 40% of rentals on airbnb - it is my contention that airbnb is doing a YouTube - basing its growth on breaches of copyright / lease law whilst hoping to grow big enough fast enough for it to not matter.

I think a better analogy is ticket touting - you buy a ticket at the baseball game and then sell the seat again, leaving when the next buyer turns up. And you only buy at "public good" rates and sell at "market rates"

This app would also go out of business if SF city sold parking places at market rates - there would be no margin.

In all, it's a silly app trying to create an after market in something where they and their customers have no legal rights and no practical enforcement, and I think they were hoping to scrape enough and not get noticed.

</comment></comment></comment></comment></comment><comment><USER5> I don't know what to think. Devilishly clever. Instant new market. But so detrimental if it catches on...

People who live paycheck-to-paycheck wouldn't be able to afford this. If it becomes very popular, those without disposable income may be unfairly abused by the system. Till now, finding a spot has been random lottery. Pay-for- privilege will leave struggling families out in the cold (perhaps literally).

Yet to punish a company so harshly before the phenomenon has proven to be a problem in practice seems draconian. The gap between theory and reality is large. Something that's harmful in theory can sometimes prove itself advantageous in unexpected ways.

And what if the company wasn't based in California? Would there be any recourse for California to exert regulatory pressure over a company based in another state? Pg's quote "if you outlaw the future, it will just happen elsewhere" seems relevant. Maybe it's a matter of time until this app catches on in other large cities. Nobody likes spending ~30 minutes searching for a parking spot.

But it's difficult to shake the feeling that the whole concept is, well, douchey. I dislike that word, but it seems quite applicable here. Sitting in a parking space for longer than you need it in order to personally profit is pretty much the definition of a dick move. Yet should that argument alone be sufficient reason to outlaw the entire market? I don't know.

<comment><USER6> Seeking rent from public property is a a problem in itself.

<comment><USER7> You pay to get in and pay to get out. Doesn't really seem like seeking [net] rent as much as it is efficiently allocating available resources.

<comment><USER8> It's not efficient if you park longer, waiting for someone who's going to pay you, rather than just pull out and let anyone else in. Drivers are being paid explicitly for making the allocation less efficient for everyone apart from the app user. It's the tragedy of the commons again.

<comment><USER9> Closer to racket[1]: causing a problem in order to get paid to fix it

[1] [http://en.wikipedia.org/wiki/Racket_(crime)](http://en.wikipedia.org/wiki/Racket_\(crime\))

</comment></comment></comment></comment></comment><comment><USER10> I agree with Mr. Herrera, even as a libertarian. Apps like Uber and Airbnb are fundamentally different from this. You could make an argument that those apps should be regulated consistently with other business in the same market, but at the end of the day they are dealing with private property. This app takes property that is already paid for and maintained by all tax payers and holds it hostage (their metaphor is very apt). Paying for the spot gives you the right to park there - it does not give you the right to determine who comes in next, and especially not to make money off that decision.

<comment><USER7> It's unlikely you're making [net] money if you're paying to get in and getting payed when you leave.

<comment><USER11> > It's unlikely you're making [net] money if you're paying to get in and > getting payed when you leave.

Getting payed when you leave requires being willing to spend extra time when you are done -- and depends on how willing you are to do that. People with reasons for being in the spot beyond arbitrage may have other needs that make that less viable.

</comment></comment></comment><comment><USER12> The problem with this business is not that it forces people to pay high prices for high value parking spaces, rather it's that it incentivizes people to camp out in high value spaces, and that the revenue accrues to the campers and not to the city. If this app is popular at all, it's probably an indication that the city isn't charging enough for parking.

<comment><USER13> > and that the revenue accrues to the campers and not the city

Then the city should build their own version and get the money that it feels it is entitled to.

<comment><USER6> I really don't understand this mindset.

Parking spaces are a public resource. The city sets tariffs at a level it feels reasonable.

Why should this public resource be priced at the highest rate the market will bear? Why should everything in the world basically only be available to those who can pay the top possible price for something?

Why do you want to live in that world?

<comment><USER14> >Why should this public resource be priced at the highest rate the market will bear?

Because it's the only reasonable choice? Overly cheap parking is not just inherently stupid and wasteful, it also generates other problems:

"cruising for curb parking generates about 30 percent of the traffic in central business districts"[0]

You seem to think that paying for something is somehow inherently immoral, while being lucky and finding it first is virtuous and good. May I ask why?

Cities that have started using the price mechanism have seen great results.[0][1]

[0] [http://www.nytimes.com/2007/03/29/opinion/29shoup.html?ex=13...](http://www.nytimes.com/2007/03/29/opinion/29shoup.html?ex=1332820800&en=cdabf3ece6c4a862&ei=5088)

[1] [http://www.nytimes.com/2012/03/16/us/program-aims-to-make- th...](http://www.nytimes.com/2012/03/16/us/program-aims-to-make-the-streets- of-san-francisco-easier-to-park-on.html?_r=1&hp)

<comment><USER6> >> You seem to think that paying for something is somehow inherently immoral, while being lucky and finding it first is virtuous and good. May I ask why?

Of course I don't. Do go ahead and enjoy knocking your straw man though.

I just don't think that applying market principles to parts of what little is left of 'the commons' is an equitable solution, as it prices poorer people out of facilities.

<comment><USER14> If your concern is for poor people being priced out of the market, the best solution is (obviously) not to destroy the market, but to subsidize poor people. Proper pricing of parking would bring in significant revenues, some of them could be directed to pay for poor people's parking.

<comment><USER6> Why?

that just sucks more money from everyone while leaving the situation the same as it was at the start (first come first served).

It's nonsensical

<comment><USER14> >while leaving the situation the same as it was at the start

No it doesn't. Less traffic, less pollution, faster parking.

<comment><USER6> And that's just not true if you're giving money back to the poorer folks so they can afford to park again!!

This works if you price people out of the market, not if you price people out and then subsidise them back in, and it's the pricing out in the first place that is my problem with it.

Or are you saying not to give the poor some of the money so they can continue to park, but just as a bit of a bung as an apology for taking away their access to yet another public service?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Rich jerks in China bribe public parking attendants for exclusive places to park their black Audis on the street. These apps at least distribute the bribes more evenly but nonetheless they are still scummy.

</comment><comment><USER16> Not directly related, but here's Godwin (yes, that one) posting "Hitler tries to find an apartment in SF": [https://twitter.com/sfmnemonic/status/480572531749826561](https://twitter.com/sfmnemonic/status/480572531749826561) \- it's pretty funny.

</comment><comment><USER17> Perhaps regulating a cap is better than banning the practice outright. If the max price is equal to the minutes left on the meter * fare per minute, the seller will never get back more than they put in. They will just be selling back the unused minutes, which can be useful if someone puts a few hours on the meter because they don't know how long they will need it. This would prevent scalping, and if parking is considered a public good, it will bring the minutes paid for / minutes used ratio closer to 1, which should be the goal. I understand that it's probably not the goal of the app creators, but it is a reasonable compromise. Of course, this type of efficiency means more social benefit and lower revenues for the city, so that's not likely to happen.

<comment><USER18> regulating = endorsing.

Regulating badly is usually worse than not regulating at all.

<comment><USER17> I tend to agree with that sentiment.

I suppose I was just thinking about the city I live in. Here, the meter prints out a receipt that the driver leaves on the dash of the car. People often will give the receipt to someone else when they are leaving their spot. Of course this practice is illegal, but I don't think it should be if the spot was paid for. Of course, it would be douchey if people started selling these tickets for high prices (that would be seeking rent from a public good), but I would have no problem buying a ticket off of a guy who wants to get his remaining three bucks back.

But I suppose you are right, there is no "good way" to get something between price gouging anarchy and outright banning of the practice.

</comment></comment></comment><comment><USER6> Good.

Monetising antisocial behaviour is not to be encouraged.

</comment><comment><USER19> In this case, you have someone pay a small parking meter fee and then they sit in the public spot waiting for someone to offer them more than their original meter fee.

This is very similar to domain name registration. You have someone pay a small registration fee (~$12) to register a domain and then they sit on that domain waiting for someone to pay them substantially more for it.

If it is ethical for a domain name market to work this way, why is a parking meter market different?

<comment><USER20> Because domain names aren't public property.

</comment></comment><comment><USER6> Hey, I should do this with tables at popular restaurants during peak hours too. That's not being an asshole, it's letting the market decide!

<comment><USER8> You can book a table at restaurants. Maybe booking a parking would be a thing to look at instead.

Being paid for leaving the place actually creates market for people who would bend the rules for profit. For example get a low-mpg/electric car that you drive around, take any space, then immediately resell it. Even worse, if you get together with others, you probably could create enough artificial resource scarcity to lift the prices to the level that makes doing this all day long profitable.

<comment><USER6> Not all restaurants. Maybe that lunch place that's real popular, you know the one, where seating's unreserved. I could really draw out my meal until the right person comes along and pays me to move on.

But yes, I agree, this whole thing creates incentives that add up to a bad situation for an allegedly public resource.

</comment></comment></comment><comment><USER21> If SF can devise a system that notifies drivers of a free parking spot for less than it currently costs - go ahead and implement it.

But I have admit that I doubt there is a cheaper way. And city probably has more important problems to solve.

<comment><USER9> A decent transportation infrastructure -- whether it's cars (with associated parking) or trains or buses or bikes or footpaths -- is an essential function of local government.

</comment></comment><comment><USER22> "creates a predatory private market for public parking spaces that San Franciscans will not tolerate"

Right, because I've never driven around Nob Hill for an hour trying to find parking, only to have to give up and pay $25 for a garage. The response from the city makes more sense if you've never actually had to do street parking in the city. When I'm at my wit's end, driving around the same streets continuously, I'd gladly have paid $7 for a spot. Have the time you don't even find a spot, you find someone leaving and take the spot immediately.

<comment><USER9> It's easy to see this as a foolish reaction of "there is a market? But markets are unfair because money, so let's stop it!" by the city of San Fran. In fact, it would take remarkably little to make me believe San Fran was that foolish.

However, these apps also create incentives for people _to not give up their spots_ until someone pays. It's an incomplete market, where someone sits on a shared resource until paid to move.

The reality is that SF should be auctioning off these spots on its own. Let the market decide what the price of parking is, and pay the supplier.

<comment><USER23> Why "should" SF be auctioning off these spots? To maximize revenue? Is that why public services exist? Are they doing a larger disservice to the people of SF by NOT auctioning them off, thus raising the price to park, over having a lower price solution to $25 parking garages? Maybe SF should build a couple of public parking garages themselves if they, as a public service, wish to continue to offer more affordable public parking. The residents of the city need affordable parking. Unless, their goal is to get less people to drive in the city and take public transit. There are so many factors at play here. So many agendas and concerns. So I repeat my question... for what reasons "should" SF auction off the spots? What are its ramifications? I have no skin in the game, I'm just an east coaster. These issues are hardly ever so cut and dry as to whether a market exists or not.

<comment><USER22> When I had my car in the city, I took public transit every chance I could because I didn't dare lose my parking spot. I only used the car for out of town trips. Then I realized how ridiculous it was to own a car that I was stressed out to use. I switched to Zipcar and never looked back (in fact, my local Zipcar garage is closer than how far away I normally had to park).

<comment><USER23> You mention the Zipcar garage. Why doesn't the city build a couple of these garages? Why don't they offer an affordable solution in that respect? What if they got rid of on street parking all together and created more parking garages so that they took up less acres and they could then reuse that street space for more driving lanes or bike lanes or bus lanes etc? They could then have more parking spots in a given geographical area and better public land use overall. I think that affordable and plentiful parking is vital to most downtown areas. Private industry will only put in so much parking themselves to maximize revenue over and above the purpose of the service itself.

</comment></comment></comment></comment></comment><comment><USER13> AIUI, this is people paying for, and parking their car in a city-owned car parking space, and then giving up that space to someone who's willing to pay more money for it.

This is simply arbitrage, and it's legal when Wall St fatcats do it, it should be legal for everyone. If the city objects, they should charge the market- clearing price for parking. If that leads to a problem where only rich people can park, then California should build as much low-cost housing as it takes so that everyone can afford a house without paying an arm and a leg.

<comment><USER8> I see it as something very close to protection racket. This app creates an incentive to take the space for longer than necessary and get paid for freeing it up. Maybe as an add-on you won't get your car scratched for an extra payment?</comment></comment>


Bug report on Zuckerberg's timeline, or: how to make one heard properly - <AUTHOR> http://khalil-sh.blogspot.de/p/facebook_16.html

<comment><AUTHOR> Note how he didn't get the bug bounty: after attempting to tell Facebook twice and got "nobug, wontfix" answers, his third (and successful) notice got answered with "We are unfortunately not able to pay you for this vulnerability because your actions violated our Terms of Service."

Great whitehat marketing on Facebook's side there.</comment>


Node.js is forked, not fucked - <AUTHOR> http://wesleyio.tumblr.com/post/104637877991/node-js-is-forked-not-f-ed <comment><USER2> This piece is (by far) the best written on the io.js fork and its ramifications. As I have said many times before, we are forkaphilic[1] -- forking is healthy because it allows (and encourages) experimentation with divergent ideas. The primary idea that io.js appears to be experimenting with is "more frequent releases", in particular very closely tracking V8. This is somewhat ironic because the close tracking of V8 has been a major contributing factor to the delay in 0.12: despite good intentions, V8 breaks node.js frequently -- and debugging those problems is a time-consuming and arduous task requiring a great deal of technical sophistication. We have made clear that our technical priorities for the project are production-grade stability and performance; to the degree that other have different priorities, forking should be encouraged. In part to allow cross-pollination from any fork, we eliminated our CLA earlier this year[2]; the community can rest assured that good ideas from either will be able to be in both.

[1] [https://www.youtube.com/watch?v=Pm8P4oCIY3g#t=23m43s](https://www.youtube.com/watch?v=Pm8P4oCIY3g#t=23m43s)

[2] [https://www.joyent.com/blog/broadening-node-js- contributions](https://www.joyent.com/blog/broadening-node-js-contributions)

<comment><USER3> > _despite good intentions, V8 breaks node.js frequently -- and debugging > those problems is a time-consuming and arduous task requiring a great deal > of technical sophistication_

Can you provide some examples? I'd love to see some debugging war stories.

<comment><USER2> TJ can provide examples from his perspective; my personal examples are all from keeping the node.js production debugging facilities[1][2] operating properly. We have tried hard to make these facilities independent from V8, but the reality is that they encode how V8 operates and that changes to V8 can break them. Fortunately, the node.js DTrace ustack helper[3] -- by far the more intricate piece -- hasn't needed major maintenance, but the facilities for iterating over all JavaScript objects from a core dump (for example) have been broken quite a few times. I'm afraid the war stories from debugging these aren't terribly heroic -- they boil down to one of the node.js debugging tests failing and Dave Pacheco or me (exactly which one frequently being adjudicated by fingers-on-noses) sitting down for several intense hours to learn how V8 has changed and modify our debugging support accordingly. If you want to see the details of the changes needed to accommodate V8, you can look at some of the specific commits for the debugging support.[4]

[1] [http://www.joyent.com/developers/node/debug](http://www.joyent.com/developers/node/debug)

[2] [http://www.slideshare.net/bcantrill/goto2012](http://www.slideshare.net/bcantrill/goto2012)

[3] [http://dtrace.org/blogs/dap/2013/11/20/understanding- dtrace-...](http://dtrace.org/blogs/dap/2013/11/20/understanding-dtrace- ustack-helpers/)

[4] [https://github.com/joyent/illumos- joyent/tree/master/usr/src...](https://github.com/joyent/illumos- joyent/tree/master/usr/src/cmd/mdb/common/modules/v8)

<comment><USER3> Thank you, I will definitely check those out.

</comment></comment></comment></comment><comment><USER4> Forking is healthy. In the late 90s/early 00s, you'd hear about a new Linux fork almost every other month. Those forks would die quickly, but sometimes would have something to contribute back to the larger distros.

The fact that Node is popular enough to fork is a good thing. There is an inherent disagreement between Joylent and the Io.js folks, not on technology but process, and it's likely that the conflict will be resolved that way they always are (the more suited fork will win out). The risk of fragmentation is very low.

<comment><USER5> There were some notable fork successes which overtook the original; egcs is the one that comes to mind. There's still a huge variety of distros, mostly RPM-based. And the three BSDs. And Lucid/Xemacs.

<comment><USER6> To clarify, Xemacs is a fork, but almost nobody uses Xemacs any more.

</comment></comment></comment><comment><USER7> The only thing I worry about is while packages will be npm compatible, if they want to take iojs to another level as far as features go you will then have npm packages that either only work on iojs or you will have polyfill libraries for iojs features to work on node.js.

Yeah this doesn't mean node.js is "fucked" but if they use npm in iojs with packages that take advantage of new API calls any node user is going to have lots of issues.

Edit: Having said that I am excited to possibly get newer versions of V8 server-side; I can't wait to start using some ES6 in a place where I don't have to wait for browsers to update.

<comment><USER8> If you can implement the new features with polyfills, why do you need io.js in the first place?

<comment><USER9> Having them used out of the box would make them more robust.

<comment><USER10> NPM dependencies are a very robust method for ensuring that a module has what it needs to function "out of the box". What else are you looking for here?

<comment><USER9> Do you mean to reply to me? I made a commeny about innovation in the stdlib would be good. and I'm quite happy with io.js supporting npm.

<comment><USER10> _> >>>If you can implement the new features with polyfills, why do you need io.js in the first place?

>>>Having them used out of the box would make them more robust.

>>NPM dependencies are a very robust method... What else are you looking for here?

>Do you mean to reply to me?_

In light of nawitus's comment, I interpreted your comment as an alleged reason IO would be necessary, given the existence of polyfills. This reason didn't make sense to me, because npm dependency installation for node is just as automatic as anything in IO could be, whether it uses npm or not.

<comment><USER9> io.js is doing new things, they might be polyfillable on top of node, but more people will use new versions of inbuilts like 'process' of 'fs' if they're in io's stdlib than if they're in some optional module people could (but probably won't) install on node.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Forking is forking. Most forks are benign. Some forks may turn out good. Some may turn out bad. Forking is neither good or bad. Forking is forking.

</comment><comment><USER12> It's easy to paint Joyent as the issue, but the root cause is the core contributors are split on their expectations and how they choose to handle them.

</comment><comment><USER13> Sounds like a healthy split to me. Let Joyent handle the risk-averse companies that require a stable tool, and let the community explore the future of V8 server-side javascript. I'm sure some of iojs' successes will find their way into node.js as well.

<comment><USER14> > Let Joyent handle the risk-averse companies that require a stable tool.

Node is stable.Like too stable without even hitting v1.

I remember a video where Douglas Crockford predicted that,saying Joyent behavior has been childish.

[http://youtu.be/8HzclYKz4yQ?t=22m32s](http://youtu.be/8HzclYKz4yQ?t=22m32s)

</comment></comment><comment><USER15> > "The last thing we want to have happen to the Node ecosystem is to create a > Python 2, Python 3 situation".

As a long time Python user unhappy with the 2 vs 3 thing, is not the Node vs IO thing very different? A fork (Node) vs two versions being managed by the same group (Python)?

<comment><USER16> It's different but if IO/Node diverge too far, it could break packages.

<comment><USER4> They're both MIT and likely to stay MIT. They don't have to diverge at all unless Joylent goes open/closed.

Edit: Downvoters, have I said something that is untrue?

<comment><USER17> The whole debate is over uptake speed. If async functions and lambda arrows land in IO and I use them in my package, people on node v10 aren't going to be able to use it.

If Joyent accepts new features as quickly as IO, there's no point in the fork.

Essentially, there's bound to be some level of fragmentation.

<comment><USER10> What this scenario means is that there should be a way for a module to depend on polyfill modules, _only for particular engines_. So on IO the dependency would not be in effect, while on e.g. node v0.10 it would. I don't think this is possible now, but you could just publish two modules.

</comment></comment></comment></comment></comment><comment><USER18> With both libraries MIT licensed, there could easily be movement of code from io.js to node.js once the team at Joyent were satisfied that the code has been done correctly.

I fail to see how there can be controversy over forking MIT licensed software.

</comment><comment><USER19> Very reminiscent of merb (a wycats led divergence from Rails from about 5 years ago). I expect a similar arc for io.js: a couple of distinct technical fetures that lead to a brief period of rising developer mindshare, then in a upcoming version node.js will promise to embrace/extend whatever makes io.js "better" and the project will peter out.

<comment><USER20> It's not technical features so much as an open governance.

More apropos is egcs, where the FSF eventually abandoned their gcc and blessed egcs (and their maintainers) as the official gcc.

</comment></comment><comment><USER21> This is the first time I read about this drama, can somebody explain to me why getting forked is bad thing..?

<comment><USER22> Well at a minimum you are dividing the development efforts between two different pieces of software. Which means (arguably) net contributions for either one should be less then if all contributions were going to a single project.

<comment><USER23> Forking is the sexual reproduction of the software world. Yes, just like the living world it takes a lot more resources to reproduce in this method, you end up with a much larger number of variants. These variants can fill various niches, such as security, speed, or ease of use. Most variants will get neglected or die off, but many will succeed, and some may be reincorporated into the original project (cross-breeding).

<comment><USER24> Wouldn't forking be asexual reproduction? Only one parent...

<comment><USER25> But asexual reproduction can also be known as cloning! Just a bad/unfortunate analogy.

</comment></comment></comment></comment></comment><comment><USER26> "The future of javascript looks bright, sunny, and full of callbacks. I'm excited." <\-- Great opening

<comment><USER27> I prefer a different promise of the the future.

<comment><USER28> There's no way to work "coroutine" into a natural-sounding sentence, but that's Brendan Eich's vision of the future of async handling in JS.

</comment></comment></comment><comment><USER29> [https://www.youtube.com/watch?v=HDZs0S7qd64](https://www.youtube.com/watch?v=HDZs0S7qd64)

</comment><comment><USER30> does anyone know where Ryan Dahl is these days? I'd be interested in what he has to say.

</comment><comment><USER31> Link should be changed to permalink: [http://wesleyio.tumblr.com/post/104637877991/node-js-is- fork...](http://wesleyio.tumblr.com/post/104637877991/node-js-is-forked-not-f- ed)

</comment><comment><USER32> I was expecting a screed against juvenile sexual innuendo, but this was good too.

</comment><comment><USER33> One guy gets paid to write about meaningless micro trends, another guy gets paid to blast him. Nothing to gain from this in my humble opinion</comment>


Innovation is a Fight - <AUTHOR> http://www.randsinrepose.com/archives/2012/11/11/innovation_is_a_fight.html

<comment><USER2> Sure Apple has it's challenges. I'm sure all of us can agree.

However, to me Steve Job's "visionary son" is not Forstall but Ive. Ive embodies the values that Jobs had regarding innovation (not surprisingly he was one of Jobs' best friends and spent the most time with him of all of Apple's executives).

Personally, I think it's possible Ive can be underrated. Sure, people value his hardware design. But can he design software interfaces? Most people would doubt he could. Yet this is the major task Ive is now entrusted with.

I'm not sure if Ive can do software design well, but I wouldn't be against him. I think he's got years of innovation experience and understanding the essence of simplicity and user experience.

I'm hoping Ive can surprise us all, and lead a resurgence in Apple with some killer new devices. I'd love to see him make a watch (or pendant) that connects with your phone but allows you to access key features. Of course there's also the TV we've been waiting for (and the backend services).

I also think Apple could get into household/home devices (ie., the Nest). It could be interesting if Apple bought Nest and expanded into the automated home.

Lastly, this is a far-fetched dream... I'd like Apple to buy Tesla. It would be pocket change for Apple ($3-4 billion market cap, but probably more to buy them). But could open up a decade of huge innovation that Apple pours into cars. Tesla has a great start, and Apple would just get behind them. Imagine iOS integrated in your car. That would be awesome.

<comment><USER3> I agree with everything but the last bit about Tesla. First, I don't know if Musk _wants_ to sell. Two, I think Tesla has the potential to be a revolutionary company on the scale of Apple or Ford. I think being owned by Apple could stunt that potential.

<comment><USER4> There's no way Musk wants to sell. Tesla is still his baby and personal goal as much as SpaceX is. I think he'll only be willing to sell both _after_ he's "solved" space travel and electric cars.

<comment><USER2> I agree than Elon Musk probably doesn't "want" to sell Tesla. But if Apple offers $10 billion and presents a clear vision of how they're going to take Tesla and propel the electric car movement even far beyond what Tesla is thinking... then, I think it might be interesting to Musk. Elon Musk's main goal with Tesla is to expedite the transition of vehicles to electric power, and if Apple somehow can convince him that they have the same goals and can do it at larger scale, it possibly could work. (Just fyi, here's Musk's "strategy" for Tesla in 2006, [http://www.teslamotors.com/blog/secret-tesla- motors-master-p...](http://www.teslamotors.com/blog/secret-tesla-motors- master-plan-just-between-you-and-me) .)

</comment></comment></comment></comment><comment><USER5> I am a huge Apple fan. I have had numerous iPhones, MacBooks, iMacs, etc. I've coined it the "law of large companies" - eventually they get their lunch eaten by someone who doesn't yet exist and they could never see coming.

With Apple, Steve Jobs has implemented a lot of policies that try and stave this off (a single P&L, cannabalization of their own products, etc.) but I'm concerned, as "Rands" is, that the ossification of upper management will reduce the agility.

See: IBM, Microsoft, Yahoo. It'll happen to Google, and it'll happen to Apple. It seems as certain as the laws of thermodynamics. As a company gets bigger and exists longer, the probability that someone is going to disrupt them approaches 1.

<comment><USER6> Except, as IBM proves, being disrupted need not be fatal. The certainty that another giant will arise seems obviously to approach 1 over time, but that Apple will die rather than successfully re-invent itself less so.

The Hudson's Bay company was incorporated in 1670, and has been in continuous operation since. It's one of the dominant big-box stores in Canada, moreso since Eatons closed down, and in the U.S. owns Zellers and Home Outfitters. The tech industry seems to have a very dark view of corporate lifespans because of the apparently quick cycle of birth and death, but it's not obvious that it has to be that way, even over centuries.

<comment><USER7> Useless trivia. The Hudson's Bay company's largest sale ever was the sale of Prince Rupert's Land to Canada.

For Americans, the amount of land sold was larger than the Louisiana Purchase.

</comment></comment></comment><comment><USER6> Talk of Apple's doom always reminds me of the saying "economists have predicted 12 of the last 4 recessions."

</comment><comment><USER8> I don't think these product categories can last forever, they've had 3 massively disruptive products since Jobs returned in my view (and many others) iPod, iPhone & iPad.

iPod sold really well, but it peaked in 2008, it's unlikely to explode again. [<http://en.wikipedia.org/wiki/File:Ipod_sales_per_quarter.svg>]

There is clearly strong competition for the iPhone with Android, with Nexus 4 (and others) coming at much cheaper price point it's not clear they can hold the margins they had.

The iPad seems to still be doing well and particularly the mini seems to be well received - but how long is that going to last with the Nexus 7 & Kindle Fire bringing the price expectations down.

Apple really needs another product category - something you can see that Steve Jobs with is background as a entrepreneur, particularly failing at NeXT while away from Apple - was a master of. It's not clear who will lead the new product category, neither Tim Cook or Johnathon Ive are entrepreneurs and it's not something they are likely to learn while at Apple.

<comment><USER9> Well what product is really burning with suckage and can be really improved? The music player, the smartphone and the tablet were all there and apple approached what it should be. The smart tv? Cameras?

<comment><USER8> TV clearly sucks at the moment.

Why can't I watch any movie ever made at the touch of a button/tablet?

Why can't I watch any series produced in the U.S. (or anywhere) as soon as it's available from U.K. (or any non-US country)?

Why do [in the UK] do Sky & Virgin control much of what you can watch?

Why do I have to manually choose what to watch, shouldn't the TV know what type of thing I like?

I've missed the 5 episodes of a series, why does the next episode only catch me up on one?

and so on.

Not sure about cameras, the main problem with discrete cameras is that it's too hard to upload the photos on the move, but that's changing quite quickly now with WiFi and/or Android cameras. Essentially Apple have a solution to that anyway, which is to just use your iPhone which many are happy with.

</comment></comment></comment><comment><USER10> Apple may not collapse or be doomed, but it could definitely stagnate and become passé. I once worked with for a Jobs-ish type GM and agree with Lopp's thesis that a leader who can maintain a high level of discord without letting it destroy the organization is much more likely to see brilliant innovation arise.

</comment><comment><USER11> As much as it is possible for a large company to reflect a single person's taste and judgments, Apple reflected Steve Jobs.

Can anyone imagine Jobs working under someone else in some multi-billion dollar corporation like Apple? I can't. Scott Forstall can -- take that for what you will.

Jobs _founded_ Apple. No other person (besides Wozniak) has that kind of claim on Apple, or could run it the same way as Jobs did.

Looking for the next Steve Jobs at Apple is pointless: people like Elon Musk will found their own companies, just like Jobs did with Apple.

</comment><comment><USER12> Conflicting methodologies is a great way spur innovation by forcing the best of each to try and out do each other. This, however, isn't why Apply is successful.

Employees famously hated even being on the elevator with Steve. What ever the employees made, it wasn't good enough. Even if it was. This turned mediocre, or even great, products into top products.

</comment><comment><USER13> I really don't understand the last sentence: >Love him or hate him, Scott Forstall's departure makes Apple a more stable company, and I wonder if that is how it begins.

What does he mean by 'it'? Demise of Apple or being a stable company?

</comment><comment><USER14> The concept of fighting is not mutually exclusive from the concept of collaboration. However to achieve results, each participant must be willing to fight in good faith, and bow to the better idea when it becomes obvious. Going by the published accounts, Forstall no longer was doing this in Apple.

</comment><comment><USER15> Apple can take one of two directions

\- focus on data, like google does, by massively investing in siri (they should make forstall in charge)

\- focus on design, but expand out of consumer electronics (which will shrink) into cars and robots, like tesla and rethink robotics (tim cook and jony ive are the right people for that)

Their current niche, square screens and possibly google glass is a dead end</comment>


Get your shit together, people (seriously) - <AUTHOR> http://zensavona.com/2012/get-your-shit-together-people/

<comment><USER2> I think this needs to be applied to more than just the tech startup industry...</comment>


Mobile Community Framework - <AUTHOR> http://www.uvamobiltec.com/#projects Mobile Community Framework (MCF) is a Software Development Kit (SDK) for building decentralized group or community based social network Apps for Smartphones. MCF enables more than instant communities and mobile groups, it enables Apps to be peer-aware, so you can find your friends or vendor services, and proximity aware so you know when you are near to them – and alternatively, they can also find you, if you so choose…
This SDK is Cross Platform enabled and available for iPhone™, Android™, Windows Mobile™, Nokia's Symbian™ and RIM's Blackberry™ OS. It was designed from the ground up to be cross-platform and behaving the same regardless of the underlying network protocols and topology. The MCF has been designed with international markets in mind, so is completely compatible with all languages, and on all platforms.
Mobile Community Framework (MCF) is an application-oriented general purpose communications framework for mobile devices.
The data transfer function within MCF is abstracted, such that applications deal with channels and buffers at a higher level than typical transport-layer concepts like sockets and network addresses. Each device can support multiple MCF-compatible applications at the same time, and each such application can use one or more prioritized and multiplexed data transfer channels, with automatic flow control and connection maintenance. All of the communications between devices, whether assisted or direct, are encrypted.
The MCF supports direct connections between devices within proximity (Wi-Fi Ad-Hoc connections), and connections between devices residing at arbitrary geographical locations (automatically routed connections via proxy server in GPRS/3G cellular mode or over regular Wi-Fi). In both modes of operation (direct or proxy-assisted), in addition to the transport function, MCF offers a function of discovery of devices and applications according to various criteria, such as immediate proximity, distance from the device, presence of certain applications, as well as various application- or user-defined custom criteria (user id, contact info, etc.). Direct communications over Wi-Fi Ad-Hoc provide for a much better range and speed than Bluetooth, which is typically used on mobiles in similar scenarios, while connectivity over proxy server guarantees staying connected in the absence of Wi-Fi Ad-Hoc devices, or simply for bigger effective communications range.
The connectivity and discovery API that MCF provides to application developers is the same regardless of the mobile platform. The API is natural and easy to understand, so making applications compatible with MCF is straightforward; for instance, adapters to various social networks can be easily designed.
The MCF is integrated with Zero-Effort Mobile Advertising technology, thus not only offering developers the transport and discovery services, but also an easy monetization of their apps without the need to resort to extra complexities associated with third-party ad network integration and subsequent maintenance. As well, the MCF takes advantage of location on all platforms, for both advertising and proximity functions.
Internally, the MCF has industrial strength processing core, based on loosely-coupled set of components, with unified dispatching mechanism between them. This approach, underlined by the design with industry-standard UML tools, and for all mobile platforms, provides clear, documented, stable, expandable, testable execution environment, both on devices and the proxy server. Event-based processing reduces power consumption.
The proxy server part of the framework is Linux-based, coded in C++ for performance, runs on Amazon cloud, and is scalable on demand, if necessary. All of the components of the device-side MCF, depending on the mobile platform, are designed with low-level languages, such as C++ or Java, for performance, compatibility, portability and low memory footprint.
To participate in Beta testing the MCF, please send a brief e-mail to email@example.com, with your name, e-mail address, phone number and a note why you'd like to evaluate the MCF and what kind of application you're considering to build with it. We will provide full support in adapting your application to MCF and testing it. <comment><USER2> Hmmm... So your framework is cross-platform on all C++ mobile platforms (WinMo, iPhone OS, Symbian)? How is that possible? These platform are quite different in terms of APIs and the rest stuff...

<comment><AUTHOR> The platform has a universal object-oriented core, with most of the interfaces generated automatically from UML models. The OS-specific parts are separated into problem-specific adaptor code. The communications happen via standard abstracted interface on developer side and standard protocol on network side, whether it's via Ad-Hoc or proxied connectivity. Furthermore, the same techniques and solutions apply to Java and J2ME on Android and BlackBerry platforms. Hope that helps...

</comment></comment><comment><USER3> Have you already some apps to demonstrate how it works? Could you give a link to AppStore?

<comment><AUTHOR> The apps are coming soon. A cross-platform "Clooloo Communicator" app is coming, accompanied by a game, also cross-platform. The Communicator is a chat and flirt messenger taking advantage of proximity scenarios. For instance, it can find people nearby on WiFi ad-hoc network and communicate with them.

<comment><USER3> I've just watched a video on your web site. That's pretty great. Is it free to join for beta testing?

<comment><AUTHOR> Yes, it is. Just shoot an e-mail to email@example.com.</comment></comment></comment></comment>


Mr. Rogers: Can you say hero? - <AUTHOR> http://www.seankilleen.com/2013/03/mr-rogers-can-you-say-hero.html

<comment><AUTHOR> I've reposted/reformatted an excellent profile of Mr. Rogers from 1998. In the context of today's lack of civility (one need only look as far as HN's comment threads at times), it provided me with a fascinating look back at a time I sometimes desperately miss.

NOTE: The article is not mine, and I was unable to find the original. I've reached out to Tom Junod, and if I hear back from him, I'll be posting a link of his choice and any comments prominently at the top of the article.

</comment><comment><AUTHOR> Update: I've received word from the author that the text can be purchased via Byliner, so have included that information as well. Waiting to see whether or not he'd rather the text be removed as well. Thought it important to update here to ensure folks knew that.</comment>


Show HN: VisitThem.org – In person congressional visits - <AUTHOR> https://www.visitthem.org/ <comment><USER2> The site is pretty.

Unclear on what to do after I see the list of representatives. Perhaps some resources (or links that lead me to resources) that show me the representative stance and best way to influence would help out. The map, address and hours are already pretty helpful though.

Also, it wasn't really obvious what benefit of signing up if you just click the sign-up link the top. Perhaps advertise on the sign-up / login page as well ?</comment>


One-time Secret: Share passwords etc with URIs that work only once - <AUTHOR> https://onetimesecret.com/ <comment><USER2> Please don't use this for passwords. Security is very hard to get right.

Do they do a secure delete of the contents of the webpages? Who knows.

Do they have strong physical protection around the server? Who knows.

Do they run up to date software so the machine can't get taken over? Who knows.

Can you even trust them not to log all your passwords? Who knows.

This is an interesting service for some things, but I would never use it for sending passwords (or anything equally sensitive) back and forth.

Even if you let me "encrypt" the information before uploading it with a password, if this encryption is done in javascript sent by the server then as soon as the server is taken over you can't trust the encryption.

<comment><AUTHOR> Nothing is entirely secure. We're two guys with no ulterior motives that take all reasonable precautions to keep the data safe. For most people that's not only enough, it's much better than having their passwords stored in their email archives and chat logs.

<comment><USER3> If the link is sent unencrypted a potential email relay or packet-sniffer could scan for the links related to your website and open it before the recipient. It would be easy to automate at any level. They wouldn't have context, sure, but they'd have whatever it is you wanted to send and your recipient wouldn't.

I don't think this is likely to happen.

Is your delete permanent, if not secure?

<comment><USER4> All of their http traffic redirects to https.

<comment><USER3> I didn't mean in reference to their site, but how the end-user transmits the link to a recipient.

<comment><USER5> The idea is that would be detectable because the recipient would no longer be able to view the actual link and the password can be changed again.

</comment></comment></comment></comment></comment></comment><comment><USER6> User receives password URL on an iPad, opens it, loads the destination login page, switches back to password tab, but it's gone forever because the iPad closed it to harvest memory.

User gets URL via webmail on Chrome, Chrome pre-fetches the URL. User closes Chrome because Starbucks is closing. When she finally visits the URL for the "first time" it's nuked.

Etc. etc.

Unexpected behavior is unexpected.

<comment><USER7> Chrome prefetches DNS, not URLs.

<comment><USER8> Chrome beta does prefetch URLs: download the latest version, go to a Wikipedia page, wait a few seconds then click the first link – it should appear (almost) instantly.

I don't know if it prefetches links in webmail, however, and that would be about the only situation I can think of where this might happen.

Edit: of course, now that I posted this, I can't seem to make it work. I promise it does happen.

</comment></comment></comment><comment><USER9> Interesting case of abuse: Send anonymous death threats as secrets. Would be hard to prove the message ever existed without server logs. Also, botnet c&c messages. WikiLeaks leaks! Damn, this is a useful tool.

Also, unfortunate for anyone trying to share the secret over the internet: if a repressive regime is sniffing traffic and looking for these URIs and grabs the contents first they can still discover the messages of dissidents before they get passed on.

<comment><USER10> Actually this service is perfect for finding out if someone has been snooping, since the "secrets" disappear on viewing.

</comment></comment><comment><USER11> A neat idea would be if you encoded the information on your server with a secret key, then put that key in the URL in addition to the unique identifier. This way you never store the information on your server. The secret key should never be put in your logs until the information is accessed and destroyed. If this policy is followed it would alleviate some fears of giving all my secrets to a third-party site.

<comment><USER12> In order for this to work, the key would have to be generated client-side and the secret encrypted client side. And you're still trusting that the site doesn't send the key when you submit the form.

While I think that this is a good idea, I hink that this would unfortunately result in URLs that would be much too long to be user-friendly - especially if we are talking about sending information to non-technical people.

<comment><USER13> An AES key is 128 bits, or 22 BASE64 characters. That's reasonable, and you can switch to BASE96 or Unicode.

This doesn't help if the server is malicious, but it does help if the server is honest but is later hacked/subpoenad/whatever. Generating a key entirely in RAM/encrypted swap is reasonable, and securely erasing RAM is easy (securely erasing individual files is nontrivial to say the least.)

<comment><USER12> I'm thinking that their unique ID (31 char) plus the key (AES 22) is a little long for a URL:

[http://example.com/1234567890123456789012345678901/123456789...](http://example.com/1234567890123456789012345678901/1234567890123456789012)

I do like the idea though of keeping the secrets safe with a client-side (or non-stored) key. So long as it's known that it isn't about keeping the server honest, since you have to implicitly trust that they won't be storing the key.

<comment><USER13> TinyURL is currently giving out 8-character identifiers; I'm confident that those 31 characters can be trimmed a bit. ;-)

</comment></comment></comment></comment></comment><comment><USER14> I really like the simplicity of this (even down to the concise html.. next to no bloat), what is behind it?

Also, pretty cool, if you refresh the private page, it'll tell you whether or not someone has picked up the shared secret. Nice.

<comment><AUTHOR> Thanks, glad you like it. We kept it as simple as possible to get it out the door and start getting feedback.

It's built with Ruby and Redis behind thin and nginx.

</comment></comment><comment><USER15> The guys behind behind Zencoder released the same thing more than a year ago: <https://www.thismessagewillselfdestruct.com>

<comment><AUTHOR> Cool. I hadn't seen that. I like the way they handle the password.

</comment></comment><comment><USER16> I also do something like this for <http://jsonifier.com>. I had users requesting that JSON pastes could be deleted after they were requested once. So, I know people find these kinds of features useful. I didn't think about building an entire tool around that one feature. Nice thinking!

<comment><AUTHOR> Thanks. jsonifier.com looks cool btw.

</comment></comment><comment><USER17> They _should_ save everything that is sent with this service. They'll have a pretty good dataset to determine common passwords, etc. Then, they could use the data to help users pick better passwords. It's not an invasion of privacy if it's done anonymously, in aggregate, right!?

<comment><USER18> Agreed. Selling anonymous data (in this case to security companies, etc) is a great way for this kind of free service to pay the bills.

<comment><USER19> They could even go freemium by giving an option to be excluded from aggregate data reporting.

<comment><AUTHOR> You guys raise an interesting case we hadn't thought about yet.

Devil's advocate: how would that be better than the algorithmic approaches (weak, medium, strong indicators implemented in javascript etc).

<comment><USER19> I can't speak for the others, but let me make clear that I am being entirely facetious. Selling data of user-provided passwords in this kind of context (an app ostensibly used to provide security) is among the worst kinds of evil. Requiring, or even allowing, users to escape from this kind of evil by paying a ransom is unconscionable.

<comment><USER17> Oh my god, this whole thread is ridiculous. I need to say that I intended my original comment as a joke. I don't think it is ethical to misuse users' data, even if it's anonymous.

<comment><AUTHOR> Let's just say we're all in agreeance.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> Love it. I came into a use case for something like this a while ago, and ended up using a combination of goo.gl (to know when the person had clicked), and text converted to an image (to stop simple copy and paste).

Maybe you could also incorporate the second part. It's obviously not a guarantee the information won't be copied, but if you know you're sending it to someone non-technical, it can be made extremely difficult.

Congrats on the product though.

<comment><AUTHOR> That's an interesting idea. We could offer that as an option: "Convert this text to an image".

</comment></comment><comment><USER21> Very neat concept. I like thinking about these new classes of sites/utilities - like one I made called <http://shoutkey.com/> \- which deal with useful temporary data instead of storing loads of data forever and ever.

I'm interested to know what data store you are using (just curious)?

<comment><AUTHOR> We're using Redis. You?

<comment><USER21> Yep, Redis for me, too.

</comment></comment></comment><comment><USER22> I built something similar a few months ago: <http://whisperpassword.com/> , it includes client-side encryption and email notification (including IP address and geolocation) of when the secret was disclosed.

</comment><comment><USER23> I'm often wanting something like this, and have often thought "I should build this" - congrats/thanks for actually building it!

</comment><comment><USER24> For me sending sensitive information using a 3rd party service, no matter what the privacy policy is, is not an option.

On the other hand the amount of positive comments simply shows how bad user experience do the current solutions like GPG/PGP have and how easy it is for people to choose convenience over security, even on this forum.

<comment><AUTHOR> Here's our privacy policy: we don't care to know your secrets.

That's tongue and cheek obviously b/c you do raise a good point. Do you have any examples we could base one on?

</comment></comment><comment><USER25> Well, it does look pretty much like one of my hobby projects I did about two years ago.

<https://off-the-record.appspot.com/> or <http://otr.dy.fi/>

There is also FAQ: <https://off-the-record.appspot.com/faq> Any feedback is welcome. There is also secure pickup option on front page. Using it server logs won't show up even retrieved keys. Those could be potentially abused to fetch data from Google's backups.

<comment><USER26> The color scheme is a bit...extreme. To be honest the interface isn't nearly as straightforward, and in a small utility tool like this, that's what matters most.

</comment></comment><comment><USER27> I really like the idea, a privacy policy would be really nice though.

<comment><USER28> Agree. I know it says that you can't do anything with the data, since necessary information isn't available. But... even if its random, it is known that it is a password. So, it's feasible to build a table of known passwords, at least.

<comment><USER29> How would that work? The URL only works once, so even if they crawled every possibility, the intended recipient would never get it, and would alert the sender.

<comment><USER28> I'm just theorizing. But let's say the site gets compromised for a few days/weeks and they don't find out.

</comment></comment></comment></comment><comment><USER30> When I test this, the page is getting cached - and thus my one time secret is viewable multiple times. Interesting little quirk...

<comment><AUTHOR> Cached by the browser?

</comment></comment><comment><USER31> I wouldn't use this for passwords, but overall I like the idea, I was thinking along the same lines. I will use this for sure.

Thanks for making it.

<comment><AUTHOR> You're welcome.

The reason we use it for passwords is because there's no way to know the application or the user account associated to it.

</comment></comment><comment><USER32> I found strange that no one mentioned Privnote (<https://privnote.com>), a much older/popular service that does this but more securely since it generates URLs with keys in the fragment to encrypt the messages on client side (so that the plain message never hits the server).

</comment><comment><USER33> fantastic. any application that has a password should also provide a method to generate a few one-time log-in urls that one could use from untrusted computers/environments. These uris could be issued with different privileges: e.g. for email, providing just access to the data younger than maybe two weeks.

</comment><comment><USER34> Interesting. I had made a similar service a few years ago (sendmypassword.net) but it never got much traction outside of my company.

Do you send confirmation mails, etc after the password is seen so that the sender knows the password got there?

<comment><AUTHOR> No we don't keep any identifying information so we have no way to contact people. We only display a message on the private URI page to the effect of, "Message was received 30 minutes ago".

</comment></comment><comment><USER35> Is there an api? I would love to make a textexpander snippit for this.

<comment><USER36> What language does it use? Seems pretty easy to create a library for this if it has an HTTP API and HTML parser (or even regex).

<comment><USER35> yes thats what i was asking?

<comment><USER36> No, I'm saying that you could use the site as it is in an automated form. You just need to POST the data to a certain URL and then parse the page to extract the contents.

No need for them to have an API.

</comment></comment></comment></comment><comment><USER37> Nice app, I would like to suggest adding a copy to clipboard feature for the created link, sometimes you can miss a letter or something and the message will get lost....

</comment><comment><USER38> would love one additional field that enables a user to specify the number of minutes, hours, or days until the url auto-expires (perhaps that's two fields).

<comment><AUTHOR> Nice idea. Seems like a no-brainer for one of the "More Options".

</comment></comment><comment><USER39> Secure notes: one time readable text messages <http://sn.linkstore.ru>

<comment><USER40> It will be very difficult to impossible for a .ru domain to gain traction with North American visitors for this purpose.

</comment></comment><comment><USER41> How does this differ from sending pass-phrase encrypted ZIP file via email or IM beyond auto-delete feature?

<comment><AUTHOR> My grandfather wouldn't know what to do with an encrypted ZIP file. A lot of my friends wouldn't either.

<comment><USER41> Yes, difference in ease of use is certainly there and not ignorable. But wouldn't the need to send URL and pass-phrase via two _different_ channels would be rather difficult to communicate to 'grandfathers'? Not an impossible task but, as someone who built consumer security products in the past, it's not ignorable either.

</comment></comment></comment><comment><USER42> I can't open this website at all in Internet Explorer. Not that I'd want to, of course, but why is that?

<comment><AUTHOR> What happens?

<comment><USER43> It Breaks on my IE9 as well. Mine just sits there "loading" a white screen. Further investigation is needed. Works great on chrome/firefox/webkit.

Can't wait to start using this sucker.

</comment></comment></comment><comment><USER44> My secret was "monitored by Stella". Yikes! Perhaps lose the Stella promotion for this application.

<comment><AUTHOR> Well, it is actually monitored by Stella. What is the issue?

<comment><USER44> Really? You don't understand that the disclaimer "monitored by $human_name" on a page that contains a secret is off-putting on first reading?

Of course I know what Stella is...now. I clicked on it pretty damn fast as soon as I saw it, because I wanted to know who Stella was and why she was privy to my secret. Do you really not understand why causing the users that moment of doubt is non-optimal?

<comment><AUTHOR> Ah, you raise a good point. We monitor and track only the homepage. We don't mention this explicitly and it would be a good idea to remove from other pages to avoid confusion.

Fixed.

</comment></comment></comment></comment><comment><USER45> <http://onetime.2ch.to/> The idea is imitated.

</comment><comment><USER46> Does anyone know how much data can be passed with this tool? Also, what data is logged?

</comment><comment><USER47> Very cool idea!

</comment><comment><USER48> I think is is really neat.</comment>


Google Glass is apparently back from the dead, starts getting software updates - <AUTHOR> https://arstechnica.com/gadgets/2017/06/google-glass-is-apparently-back-from-the-dead-starts-getting-software-updates/ <comment><USER2> I suspect this is the sort of thing where someone at Google is still using theirs, has access to the code via the monorepo, decided to do some updates (maybe over a while) to fix issues they were having, and then decided to get the bureaucracy taken care of to push it out to everyone.

I don't think there's much (any?) chance of this being a sudden renewed interest in Google supporting the device.

</comment><comment><USER3> I find this use case interesting (linked from the comments in the ars article)

[https://www.augmedix.com/](https://www.augmedix.com/)

having the doctor wear google glass while a "remote scribe" takes notes for the doctor to sign off on later.

</comment><comment><USER4> AR is coming back in a big way, maybe not through the glasses at first, Google's miscalculation was not seeing the phone as the starting point in this technical evolution. As soon as the phone platform gets good enough, its time to jump to apparel.

This company -> [http://aipoly.com](http://aipoly.com) <\- is really onto a great use case for AR products, although I think their product could use a lot more work to be more applicable.

</comment><comment><USER5> Anyone know where I can get one for a reasonable amount?

</comment><comment><USER6> Why did they stop Google Glass in the first place??</comment>


Ask HN: How to teach my five-year old electronics? - <AUTHOR> Starting next month I'm going to have a 30 hour work week. I want to take this extra time and spend with my family and one of the things I would like to do is to encourage my five-year old sons interest in electricity and electronics.
I've chosen to not go down the Arduino/Raspberry Pi road (computers will come later), nor the Mindstorms road (to pricey and I'm afraid he will treat it as just another Lego kit).
What's the best way of introducing power source, lamps, resistors and capacitors? Are there good kits available? Should I make my own kits? I'm guessing a prototype board and an assortment of components would be cost effective but some kind of guidance would be nice as well. <comment><USER3> Battery, bulb, wire, fingers?

It's not about the knowledge. It's about the time together.

Good luck.

<comment><USER4> Yes!

Also motors — kids love moving toys and a couple of small motors means you can make cars and fans and stuff.

</comment></comment><comment><USER5> I think like devnonymous says, SnapCircuits are a good choice. They aren't breakable and can be quite fun to play with.

But, to be honest, 5 is pretty young for them to grok a whole lot. Most of this at this age is really about building something with you. You'll be doing most of the work, and they'll just be mastering the physical aspects of it. Don't try and explain or expect too much as it can be very frustrating to them.

Mindstorms isn't really going to help much and Arduino / pi should wait until 7 or 8.

Another good choice is Minecraft Redstone Circuits. Most kids love it and it provides an immersive way for you to build electronic systems together.

(I run a program teaching kids coding + robotics in the bay area, happy to answer more questions if you have them! contact info is in my profile)

</comment><comment><USER6> A friend of mine got something like this for her daughter, who seemed to have loved it:

[http://www.snapcircuits.net](http://www.snapcircuits.net)

I'm not sure about the current state of littlebits, but I remember it being very promising :

[https://littlebits.cc](https://littlebits.cc)

</comment><comment><USER7> It is awesome that your son has an interest in this stuff! What in particular fascinates him? I have always found it is easiest to have kids learn when it not just something they are theoretically interested in, but also has a practical application. Does he find flashlights cool? If so, build your own. Find a way to apply what he is learning and see if he can use it to solve a "problem" around the house (is a door open that shouldn't be, or make a signal his chore is complete or needs to be done).

</comment><comment><USER8> My son got pretty excited about these very simple projects after we somehow got onto a string of youtube videos about 'hacking' toy cars. For example:

How to Make a Solar Powered Toy Car at Home - <USER2> [https://www.youtube.com/watch?v=_an8AlywBrQ](https://www.youtube.com/watch?v=_an8AlywBrQ)

There are many others out there with just a motor, a few wires and a battery. I try to explain how things work as we go along.

</comment><comment><USER9> This will teach him electronics AND the core fundamentals of programming.

i just ordered it for my 5yr old.

[https://www.primotoys.com/](https://www.primotoys.com/)

</comment><comment><USER10> I have a 4 year old and I second snap electronics kits. It is much easier to let them help you snap together pieces than it is to deal with a bread board.

I plan on teaching bread board a little later in life.</comment>


Seedcamp winners announced - <AUTHOR> http://www.techcrunch.com/2007/09/07/europes-seedcamp-winners-announced/

<comment><USER2> Seedcamp founder, Saul Klein on Playfair: "It's Excel 2.0"

I have Excel '07, and damned if I can find it's equivalent of 'Help->About', but I know '00 was 9.0, so...yeah. Poor choice of words there, buddy. :)

Edit: (Excel 2.0 was released in 1987 according to Wikipedia...awesome.)

</comment><comment><USER3> Is it just me or do all of them sound a bit pompous. Maybe the problem is that they are trying to explain something in words which is better explained in a demo.

<comment><AUTHOR> The stage where you receive seed funding might not be the best stage to be featured in writing by TechCrunch. Although three of them have launched already and two more have "a working application", it sounds like their demoing is still under development.

</comment></comment><comment><AUTHOR> Now that they've won some funding, they need to start in a new game and win the markets.</comment>


Reddit AMA with Shahid Buttar, on Leave from EFF and Running for Congress in SF - <AUTHOR> https://www.reddit.com/r/sanfrancisco/comments/8bsp7y/ama_longtime_digital_rights_activist_lawyer_dj_us/ <comment><USER2> Shahid is awesome, I would vote for him if I lived in SF.</comment>


Ask HN: Any truly revolutionary smartphone apps in 2019? - <AUTHOR> Have you discovered any iOS/Android apps in 2019 that are achieving the same results in a different, more effective way than other apps in their category? <comment><USER2> For me and my field business, FieldVibe is the only app that managed to do the job properly. To all those working on field and need a mobile first solution, I highly recommend it.</comment>


Mayday, mayday: Apple's latest ad campaign faces groans from all sides - <AUTHOR> http://arstechnica.com/staff/2012/07/mayday-mayday-apples-latest-ad-campaign-faces-groans-from-all-sides/ <comment><USER2> I was talking with a friend at work yesterday. He is a Windows/Android guy (Windows for gaming, Android because it's not an iPhone). He really liked the commercials (though he felt _Basically_ was pretty close to douchebaggery).

The point: maybe these commercials aren't geared at patting the Apple elite (I am one of them!) on the back about how smart they are. Maybe they are about introducing a different audience to Apple and we elite are too close to it to see whether it is effective or not.

<comment><USER3> That's the only one I thought was bad - I really dislike Apple picking on the small guy (the sleazy looking guy who apparently sold fake goods), and the ad doesn't end up on a positive note.

The other ones (the airplane one especially) aren't bad, and make a point - you can do things pretty effectively on a Mac. They still don't have the elegance or panache of some of the other Mac ads, but let's not kid ourselves - some of those Mac vs. PC ads were pretty horrible.

</comment></comment><comment><USER4> I can't help but feel like people are already convinved that simply beacause Steve Jobs wasn't involved that apple has lost it's magic, regardless of the actual content of the ads. If they released the Mac Vs PC ads now, people would probably denounce them as the worst ads ever made, convinced Steve would never let ads like that fly.

I would love to show these ads to two groups of 100 people and tell one half that the ads were made after Steve Jobs died and tell the other half they are the last ad series he helped work on before he died. I get the feeling the second group would be a lot more likely to spill out sentences like "oh wow, I can see the new bold direction he is taking, these ads are amazing!" or "Wow, he really knows what the current market is like, these ads are amazing!".

</comment><comment><USER5> I like these commercials. I can see why others might dislike them but I would much prefer to see these during the commercial break than Apple's more famous spots.

The "I'm a Mac" spots were arrogant. They flared rivalry and caused Mac vs PC flame wars to increase in intensity. And now-days with IBM contributing consider open source man power the 1984 spot is ironic. These new commercials are mellow, fun, and maybe a bit bland. They no longer position Macs as a social signal but rather as a quality computer. Which is the correct tactic for Apple to take when targeting the larger computer market.

</comment><comment><USER6> I have to wonder if this ad would have made it past "The Steve" while he was at the helm. It seems very out-of-sync with what they did then.

Is this indicative of where Apple is heading I wonder?

</comment><comment><USER7> I love that we expect and hold Apple to a high standard of advertising.

If they say we get the leaders we deserve (by the leaders we do, or don't demand), maybe the same is true of ad campaigns?</comment>