HN user

scottjackson

432 karma
Posts11
Comments81
View on HN
Yours vs. Mine 13 years ago

From the section of the iOS HIG about writing alert copy:

> Avoid using “you,” “your,” “me,” and “my” as much as possible. Sometimes, text that identifies people directly can be ambiguous and can even be interpreted as an insult.

> some more info on where you'll be gathering this information and how you'll choose to aggregate it

My server basically spends the week trawling GitHub for trending projects, so the scope of what can appear in a newsletter is kinda limited for now (only stuff that's trending on GitHub). In the future, I'm thinking of looking in other places (Twitter, Pinboard, etc.) for content to put in the newsletter, but the problem there is relating a link in a tweet to a particular programming language — things like PHP and Objective-C are easy enough, but just doing a search for tweets with "#python" and links in them isn't going to return very many meaningful results. So this is just a first release to test the waters and see if there's demand for something like Cccode. If there is, I plan on broadening the scope a bit. For now, though, think of it as "the hottest (GitHub) projects in your favourite language".

Thanks for checking it out!

> The best solution is to save the whole page, and annotate the bit of interest.

Agreed. That's definitely something I'd love to see Gimme Bar do: in addition to showing me the quote I pulled out of the page, also give me the option to see the full page, with the text I quoted highlighted.

> I should not have to manually initiate the dropbox backup

I'm pretty sure you only have to start it once. After that, anything you Gimme gets put into your Dropbox folder right away. At least, that's how my Gimme Bar works.

I originally thought you had to had to go to Gimme Bar's website each time you wanted to back up, like you said, but recently (maybe a month ago?) files started being automatically put into my Dropbox folder as soon as I Gimme'd them. I'm not sure what happened, but I'm glad about the change.

So, tl;dr: Dropbox backup definitely works the way it should.

As for future-proofing, I think this Gimme Bar does a pretty good job. If Gimme Bar ceased to exist, you'd still have your library in your Dropbox folder. If Dropbox ceased to exist, your Dropbox folder would still be a folder on your computer, and your Gimme Bar library would still be there.

So, for you to completely lose your entire Gimme Bar library, all three of the following things would have to happen:

1. Dropbox would have to shut down, 2. Gimme Bar would have to shut down, and 3. The hard drive on every computer you had Dropbox installed on would have to fail, as would every back-up of every one of those drives.

If you wanted to go to Siracusian lengths, I guess you could install Dropbox's server client on a VPS. That way, you'd have your Dropbox stuff in your own cloud as well as in Dropbox's, so even if all three of the above things happen, you'd still have access to your stuff.

I use Gimme Bar and love it. I also use Pinboard.

Pinboard I use for pointers to things - GitHub projects that might come in handy in the future, development/design resources, particularly interesting Wikipedia articles, and other things like interviews and magazine articles.

But there's some stuff that I want to keep. I used to have a `~/box` folder on my Mac where I'd keep pictures, quotes, and screenshots of web pages I really liked. I wanted to keep them locally so that I would always have a copy of them. However, there were problems with this. By just keeping pictures as files, I couldn't always easily find where the picture came from (not without coming up with a complicated naming scheme or moving away from the simplicity of just having files in a folder). I kept quotes in plain text, so attribution was difficult for them, too — I needed to be able to capture quotes quickly, so I didn't have time to also store the URL the quote came from. And screenshots of webpages aren't exactly interactive — if I wanted to look at some HTML to see how something was done on the page, too bad. I also didn't have a pretty way to look at all the things I'd wanted to keep. All I had was a Finder window.

I know that Pinboard's premium service can archive each bookmark I send there (I've been thinking about enabling it just so I have permanent copies of interviews), but archiving an entire page is overkill for when I just want to save one image or one choice sentence from the page. Besides, if I archive the whole page, how can I indicate which image/quote I wanted to save in the first place? Long story short, Pinboard's archiving isn't quite what I want (though, like I said, I've been thinking about switching it on for backing up interviews).

Gimme Bar is basically the best of all those worlds. I can save images, videos, quotes, and site designs. I can easily see where the image/quote/etc. came from. The site gives me a purdy way of looking at them. And integration with Dropbox means I always have a local copy of everything. Gimme Bar lets me have my cake, eat it, and have my cake stored in Dropbox (I may be stretching this metaphor).

Anyway, I really, really like Gimme Bar.

> If I remember correctly, Apple elected not to allow a 2 button mouse for a long time earlier in their history because they wanted to force developers to build apps that worked just fine with 1 button.

I think you might be thinking of the reason the 128K Mac didn't have a terminal. In that case, they wanted to force developers to make new, graphical programs instead of just porting their terminal programs to the Mac. The mouse had one button [to cater to users][1]:

> The powers at Apple concluded that because the mouse was a whole new way for users to interact with their computers, it should be as uncomplicated as possible. Hence, one button.

[1] http://lowendmac.com/musings/11mm/mouse-history.html

I sense you might be making a joke, but just in case: I'm pretty sure he means that three issues of The Daily have come out in the three days since the app's debut.

Agreed.

Related: playing through Portal with the developer commentary on is really interesting. For anyone who's interested in this stuff, it's a must-listen.

The first few panels (World 1-1 in Super Mario Bros.) reminded me of this: http://www.auntiepixelante.com/?p=465

I love having any excuse to share this link.

<quote>

the big question of level design - and i mean that every level design lesson i ever write will be a response to this question - is: how do i teach the player these rules? an unfortunate trend in contemporary games is to spell out every detail in a hand-holding “tutorial” session at the outset of a game - unfortunate because it shows both a great deal of contempt for the player’s intuition and a lack of confidence in the designer’s own design. but more than that, it’s a design failure because it tells the player the rules instead of allowing her to learn them.

what if the first level of the game were laid out in such a way that the player could learn the rules simply by playing through it, without needing to be told them outright?

</quote>

The article's a critique of World 1-1 being the perfect tutorial level for Super Mario Bros. Go read it.

It's nothing like MT, but it's a fun site. A friend of a friend contracted someone on fiverr to design a logo for a project he was working on. I saw the logo the fiverr person produced, and it was the lamest thing I'd ever seen. Which you'd expect. But still. Funny.

Fiverr's quirkyness reminds me a bit of http://highdeas.com/

(OT: my favourite highdea was this: http://highdeas.com/technology/Microwave_equivalent_cooling_...)

I stand corrected. Founders at Work, p. 41:

<quote> The very first thought in my mind was, "I think I signed a document that everything I design belongs to Hewlett-Packard." Even just on my own time, I thought that they deserved it first. And I wanted Hewlett-Packard to build this. </quote>

Good call.

I was under the impression Woz didn't realise until after the Apple I was developed that HP might have the rights to it.

From iWoz:

<quote>

Before the partnership agreement was even inked, I realized something and told Steve. Because I worked at HP, I told him, everything I'd designed during the term of my employment contract belonged to HP.

Whether that upset Steve or not, I couldn't tell. But it didn't matter to me if he was upset about it. I believed it was my duty to tell HP about what I had designed while working for them.

[Later, after getting an order for one hundred Apple Is]

I decided I should run the whole thing by HP one more time. I spoke to Pete again. He told me to run it by legal. The legal department ran it by every single division of HP. That process took about two weeks. But HP still wasn't interested, and I received a note from HP's legal department saying they claimed no right to my design.

</quote>

Oh Merciful Book Industry, please do not smite me for reproducing a few paragraphs from a book.

> HN is also running really pretty slow today.

Just my luck. As soon as HN took a little while to load for me, I knew that someone would mention it in this thread.

I made hn-api understanding that scraping HN is frowned upon, but also hoping that programmers wouldn't do dumb things with it. As I [said][1], I minimised the number of requests hn-api makes to HN.

In the readme, I say that hn-api is unofficial and unauthorised. I also tell people to be gentle with making requests to HN. Is there some other action I should take? Ideally I'd like to keep my work up, but if pg tells me to take it down, I will.

Great, now I feel all dirty like The Pirate Bay.

[1] http://news.ycombinator.com/item?id=1112267

> It's not like you need karma updates every time you do a request to the API.

Obviously.

When a request is made to get stories from HN, no HackerNewsUser objects are created (and thus, no karma gets updated). hn-api will only update karma when you, the coder, make a HackerNewsUser object or call the HackerNewsUser.refreshKarma() method.

Like I said -- one request when it gets stories or one request when you get a user's karma.

Thanks for the link.

hn-api only makes one request when it gets stories or one request when you get a user's karma -- that doesn't seem like too much. I knew there was a velocity check on IPs (and that I was making an unofficial API), so I made it as light on HN as possible.

On the Nexus, can you double-tap an area on a web page to zoom in to that area? That's one way of zooming in with one hand that I like on the iPhone. I'm just curious to see if Google brought that gesture to Android with the recent update.

The list of games written with OpenGL: http://en.wikipedia.org/wiki/List_of_OpenGL_programs

Notable games: Doom 3, Far Cry, Max Payne, the Quake series, Red Faction, Runescape, Second Life, Spore, Star Wars: Jedi Knight and Star Wars: KOTOR, Unreal Tournament, UT2004, UT3, Warcraft 3, WoW.

Most of the big-name ones default to Direct3D when they're running on Windows though.

I have very little idea of how D3D and OpenGL work (I've never written anything substantial with them), but I'm very interested in the idea of an open standard for rendering games. That portability story in the post is great.

What's the deal with D3D? How is it better than OpenGL?