nsfmc

this hasn't happened to me, but i witnessed it at Outside Lands SF this year and it is devastating to watch. there is basically zero recourse for the buyer of the ticket that scans invalid and many of them have very legitimate looking pdfs and emails they got from craigslist.

neither the ticketmaster folks nor the venue folks tend to be super compassionate in my experience. it's a real mess though, the venues often have no in-and-out privileges (possibly due to how scanning invalidates some 24-hour key), so even as a law-abiding consumer, you're stuck at an event for the whole time just to deal with ticketmaster's implementation details.

i'm sure others have said this, but that is definitely a business that wants disrupting. there's so many bits of tech that could make this experience better and safer for consumers, but i suspect ticket fees are more profitable than user experience.

but it shipped. how many projects do each of us have that just sit in a repo somewhere that we never ship because "it's just not ready yet" or because we fear public scrutiny of our code. i'll speak for myself because there's easily a handful of projects that are probably ok to "ship" but that i let stagnate because i worried about this sort of comment.

and honestly, it doesn't matter. the author has no responsibility to you or to anyone to write hardened production-ready code. if his app gets rooted, it's on him, and it's honestly the responsibility of everyone that runs it to determine if that's a risk they're willing to live with.

but the quality of the code has little bearing on the fact that this product didn't exist some while ago and now it does. maybe it'll influence somebody to create a desktop version or to contribute some security fixes, or maybe it'll just spark some design discussion. it shipped and irrespective of its quality, it's making at least one person more productive.

I had the exact opposite experience in cambridge in 2006. I saw some kids trying to steal a vespa and called the police, dispatch didn't give me any hope that the situation would actually be addressed even though i could see it happening a block away from me.

about ten minutes later, i get a call from the police to go id the kids about a quarter mile away. about two months later, i got a summons to testify out by ashmont. i didn't really connect "i see something" with "i will say something in court" when i called and it gave me an appreciation for the realities of witness intimidation.

in contrast, someone walked through my office once and lifted a couple ipads and a few wallets. mountain view police came by about half an hour later, took a report, and that's the last i heard of it. some things are easier to deal with and a small robbery like that i'm told is basically a lost cause.

i often found cambridge, somerville and medford police and fire were impressively responsive, even for relatively minor complaints, but i'm sorry you and your friends' experiences have been lackluster.

The thing i'm not totally sold on is that for arg-free alloc/inits, you can forego 'calling' those methods at all so you get code like `task = $.NSTask.alloc.init;` but sometimes you have code like `ObjC.super(this).init;`. So although you're actually initializing a new object, casually glancing through the code makes it seem that you're actually just accessing a property on NSClassName. Jstalk/cocoascript i think get this right with `NSWhatever.alloc().init()`.

Still, it's a bit weird and it makes me think that the poor folks working on this didn't know what the swift folks were doing because if they had, i suspect that the cocoa-bridged syntax would feel even more natively javascripty than it does right now rather than what's here. For comparison

    // in swift
    var color = UIColor(red: 0.61, green: .71, blue: .23, alpha: .8)

    // in js for automation
    var color = $.UIColor.colorWithRedGreenBlueAlpha(.61, .71, .23, .8);
    
    // but why not use objs for named args?
    var color = $.UIColor({red: 0.61, green: .71, blue: .23, alpha: .8})
    

Of the two, the swift feels the most js-native to me because you can easily hallucinate the {}s from the third example. But even if you're creating a js bridge and you're apple, why even force people to deal with alloc/init anymore? Even the registerSubclass syntax feels like a concession

Don't get me wrong, I think it's great that we're getting better applescript support via js, but it's definitely an area where the implementation feels like a step back from cocoascript and jstalk, at least with both of those the syntax highlighted when you were engaging in nonidiomatic behavior but at least both tried their best to paper over it.

What should have been a lightweight approach actually feels more heavyweight than writing equivalent code in swift instead, which makes me sad because i like js and i would have really liked for this to have been more approachable.

i think the question was asking for most of the content publicly accessible but some of the content hidden behind a login. google sites does something like that but i haven't seen any flat-file cms'es that offer it.

> this left the typesetter an unwelcome choice between moving the letters further apart (creating an awkward space in the lower half) or keeping them close together (creating a dense area or even touching/overlapping symbols in the upper half).

i just want to clarify that when it came to classic printing, the problem was much more pragmatic than aesthetic. The top of the f actually extended beyond the horizontal bounds of its sort[1]. If you didn't use a ligature, you risked damaging either your /f or your /i, but almost certainly you'd notice it when the line didn't pack flush. The the ligature was partly aesthetic, but it existed historically to make the act of printing work easily.

Now that kerning is better supported, 'historical ligatures' are something of a luxury, which is why they're still an opt-in feature in opentype fonts (you can see this distinction, btw, in the `rlig`, `dlig`, `liga`, `clig` and `hlig` opentype features[2]), except for brick, which is opinionated about these things.

[1]: http://commons.wikimedia.org/wiki/File:Metal_type_kerning.sv... [2]: http://en.wikipedia.org/wiki/List_of_typographic_features

i'm pretty sure you'd be reacting differently if the article was titled: easy html5 animated svgs using illustrator and jquery.

which is basically what this is proposing. i think you can be down on this as much as you want, but from my perspective, it's actually providing designers a much needed 'in' to the world of using jQuery in a productive manner. and, it requires shockingly few dependencies; you don't need to understand or spend time massaging some templating language, or less/sass, or anything other than learning jQuery events and animations.

and honestly, the more people we have that feel comfortable proposing ui changes that actually know what libraries like jQuery are capable, the better. hell, even if a novice designer only became comfortable with easing functions and timings as a result of this, it would be fine by me.

your concern that this will get hastily productized i think misses the reality that most people can't (yet) abandon ie8 which still doesn't support svg and for browsers that do, my experience is that there are still gaps between some of the svg illustrator makes and the effects that browsers support. still, for prototypes, i'd take this over a powerpoint or aftereffects movie any day.

i was skeptical about reinstalling cs4 when i upgraded to mavericks and found that it actually worked. amazing. the unintuitive part was that i needed to install java which is no longer standard on a bare osx install, but afterwards, it worked, which blew my mind. i guess ymmv.

it works fine with virtualenvs, on osx, you can do

    virtualenv env
    . ./env/bin/activate
    easy_install readline
    pip install ipython

on linux, you can avoid the readline install. i have no idea what the windows scene is, but at least for the past four or so years, i've never had a problem with virtualenvs and ipython.

i think the more subtle point, which you're free to disagree with, is that the word 'bro' has a ton of baggage around it from the offest. the word 'man' isn't chosen because it's trying to remind people who need help of the patriarchy's stranglehold on information, it's just short for manual, which i think most people can stomach.

If you wanted to parody 'manual', you could name the command 'rtfm' or 'automatic' or 'auto' or 'otto', but 'bro' has a ton of dodgy cultural baggage around it. Naming things is hard and if you want proof of how this can be problematic, look no further than this open source Buffer replacement here:

https://news.ycombinator.com/item?id=4484526

i remember seeing at least one other font trailer way back in the day, but this is the only one that i can remember a url for

http://www.trixiefont.com/

If you're worried that illustrator files are too proprietary, you should really consider working in postscript. illustrator will deal with properly handwritten postscript just fine and it's a mostly straightforward graphics dsl (especially if you're mostly doing icon design). plus, it's easy to convert to a pdf or rasterize it using any number of readily available tools.

if your concern is that the tools for creating OTFs and TTFs seem to be opaque, i would suggest you look at the UFO[1] specification which represents a font as a folder containing a series of glyphs which are, themselves, a highly domain-specific hybrid of svg and postscript. the AFDKO [2] added support for UFO last month(!), so there seems to be traction on that front. fontforge, natch, has supported ufo for quite a while.

the problem with picking on fontawesome is that for icon sets to work, they usually need to be consistent and it's hard enough to get people to agree to code style guidelines, much less visual ones which are wayyyy more philosophical.

in any case, if there's a takeaway it's to look at UFO, it will at least provide you with a free and transparent workflow, but how you manage that workflow will still be a challenge.

If you (or anyone else reading this) want to work on this problem, i'm happy to talk offline since i've been doing a ufo fork of fontawesome for work lately and have accumulated some domain knowledge on that front.

[1]: http://unifiedfontobject.org/

[2]: http://www.adobe.com/devnet/opentype/afdko.html

agreed, it would be particularly disturbing if a govt service were flaunting its blatant disregard for hippa (which, again, would be headline-worthy for that reason alone)

this is a misleading title in particular because it applies to the maryland exchange's website and not, as a whole, to 'obamacare.'

regardless, how is this any different than any other website handing over information when a lawful request has been made? is there some expectation that exchanges are immune from these sorts of requests from law enforcement agencies?

similarly, is there any question that correspondence with a public agency can potentially be entered into a public record? this doesn't actually overturn doctor patient confidentiality (which would be worthy of a scary headline), it's just enumerating the same problems you likely already need to contend with when dealing with private insurance.

interesting... but what happens with the data? i looked but couldn't find a way to recall the things i 'liked' and the recommendations didn't seem to be getting any better. as a window shopping experience, it works since i'm just randomly scrubbing through clothes idly, but i feel like i'm missing some context because i don't immediately understand how i'm supposed to use it in the long term (am i supposed to just shop for these things when i see something i like or should i just vote for them?)

fun though for what it is, i spent more time than i expected to just scrubbing around.

netflix thinks i will give it 4.6 stars...did you like The Lives of Others?

http://www.imdb.com/title/tt0405094/

  Boarding passes need to change. But here’s the question:
  Is re-structuring the information enough or is the 
  boarding pass concept obsolete?

i don't know if the whole boarding pass 'concept' will be obsolete because it basically passes the buck to smartphones, kiosks and intelligent seating (or some other novel contraption which alerts you to where your gate is, where and when you board and where your seat is). Maybe you know something that i don't, but those seem like problems that are solved handily (even if poorly) by ephemeral printed boarding passes with a minimum of fuss.

For me, the problem is primarily that the people who design boarding passes, either printed or mobile, seem to do a remarkably small amount of flying themselves (or at least they are willfully ignorant of the needs various travelers have). It's ok to assume that phones with embedded context info will solve many of these issues, but the amount of information contained in a printed boarding pass is significant and, for the most part, dependency free.

I'm not trying to be contrarian, i also want boarding passes to be obsoleted, but it seems to me that "the wayfinding problem" isn't going away anytime soon.

sadly, this was only really possible in Type 3 fonts which were basically 100% postscript interpreted at the glyph level. this made it possible to do things like actually generate a new instance of a glyph each time it was printed at the expense of printing being incredibly costly. If you find interviews where people talk about using beowulf, they all remark how it basically put their printers' cpus to actual work and that files would take forever to output.

opentype only allows for simple substitutions, but in many cases, those seem to do the trick if you programmatically generate a substitution map based on a target language's corpus. i think there's a robofont or typecon session where they talk about this and the practical limitations of how many gsubs most opentype engines can deal with before they stop altogether. very cool stuff and mega-niche, but it's cool to see how people play with constraints.

It is! Doing it right is the hard part since opentype is limited to very specific kinds of substitutions, so you don't get nondeterministic random, but you usually get something that appears random-enough. The canonical example of actually nondet-random is the font Beowulf[0], by letterror, i don't know that i can do it justice here, research it a bit to really get the story.

Two contemporary examples: Bello Script[1] and Trixie HD, although lots of people are really pushing opentype's features these days in novel ways.

[0]: http://letterror.com/fontcatalog/fontfont-beowolf/

[1]: http://www.underware.nl/fonts/bello/features/how_does_it_wor...

[2]: http://trixiefont.com/story/index.html

this is an argument at least sixty years old, if not older: http://gmunch.home.pipeline.com/typo-L/misc/ward.htm

it has people on both sides of the aisle and people often switch back and forth (see jan tschichold for the canonical example of this)

Whether or not you like arial is totally on you. In many cases, especially onscreen, arial looks perfectly fine. Many of the norms around 'good' and 'inappopriate' type are the same around fashion/clothes. You can wear whatever you want and it's on you whether or not 'you wear it well.'

As an aside, when i was in grad school, the style coming out of yale and the werkplaats typografie was this severely default design aesthetic. Times new roman massively overlaid atop a xeroxed image at times abandoning legibility. It was like high-art zine culture blended with dutch sensibility, i.e. http://ffffound.com/image/d6f63117fcf5ea64c59c66b8af85e2389d...

But to the point about what makes arial "good" or "bad" is the same thing that makes Didot a bit tough as a text face (it just wasn't designed to be used that way). And same with arial, it was designed as a screen font that prints ok. I don't think the whole "lesser helveltica" claim is entirely fair to arial, but you have to accept it for what it's for: a generic screen font. If that is the look you are hoping to rock, use it wherever you want.

And to the larger point: all prescriptive advice should be treated like training wheels. if you already have the sense to know what you're doing, you can safely avoid the advice. if you don't know how to critique your own work, then it helps to think about what the prescriptive advice is getting you to avoid.

If you are at the point where you are making intentional decisions about what your design should look like, then keep on keeping on. But it helps to be aware of the cultural baggage that those choices bring along with them. I critted somebody's poster once and made the offhand comment: "oh, that looks computery" and i was basically trying to say "that has that homemade camcorder feel that home movies have, but if it were a poster that had been made with a computer." and it turned out after some period of time that i was actually reacting, subconsciously, to the fact that it was set with arial. How weird is that? But it was because i was so familiar with that look as something that tasted digital that is seemed weird in print. It wasn't wrong, it was just giving off that vibe.

Likewise, butterick is trying to make his own mark, setting his own tone. That's his right, he's alluding to certain traditions and aesthetics. It's fashion, yes, but it's also all the choices and feelings that those fashion choices bring along with them.

i recall that even as of ~2000 php3 had @beat support via its date() function. I just checked to see if it had been removed, but it's still (surprisingly) there.

At least you can't say it failed for lack of ubiquity :)

i picked one of these up as a kickstarter backer and i was also 100% skeptical of the quality, but it's actually quite good and, more than anything, endearing.

the caveat of course is that the size and scale of the projector means you're not going to project from yards away, my best results were about a foot and a half away in a dark room, but at that scale, i was impressed at how well the photos resolved.

i disagree. fundamentally the point of these checklists is to standardize the sorts of things you evaluate during the code review. if feedback is inconsistent, you end up seeing different standards applied to several parts of the codebase which can (and does) manifest itself as an inconsistent product.

the overall appearance of the checklist does make it seem like it would be problematic, but i think the author makes a good point of showing that they act as a template for the reviewer rather than as strict set of guidelines.

in a situation where "we're all consenting adults here," having a set of things to evaluate features or code style makes it easy for anyone to know what to expect when checking in a change or when reviewing one for the first time. it may not work for you, but it certainly adds consistency when they're used non-dogmatically.

you can pay your taxes with cash, but you have to do it at a physical IRS office.

http://www.irs.gov/Businesses/Small-Businesses-&-Self-Em...

they typically have the same protections, the only difference is that while credit cards only check that the charge can be made during the authorization period, debit cards lock up the bank's funds immediately which may cause your checking account to be temporarily unusable even if all the charges are successfully disputed.

a good practice that bankers constantly tell me is to have a separate credit card for online purchases for the fact alone that it is one step removed from your checking account.

the generalized form of this technique (which you can also use to see if somebody has a font installed locally) is to basically create two rules:

    .load-base { font-family: comicsans-ms, verdana; }
    .load-test { font-family: fancyfont, comicsans-ms, verdana; }

and periodically check that the width of a line of nonsense text for both classes is not the same. Blank has the obvious benefit that it will be obvious when 0 != something else, but you can do it if you have some reasonable expectation that some other common font will exist with different metrics than your fancy font.

interesting to see the process behind the font, though.

in my experience the general sentiment is that the ORM is a leaky abstraction because it's common to make performance decisions based on the ORM's peculiarities.

up to a certain size, most ORMs will behave just fine! the bigger problem is when your mental model of how the ORM should be behaving for a certain data access pattern is thwarted by the actual implementation. This usually only happens when you notice a performance bottleneck around a semi-exotic query that you know to be trivial in sql or whatever.

it's also possible to put up performance abstractions between you and that ORM bottleneck, but often the experience and tradeoff sours most people. i don't blame them, but i agree that for most day-to-day cases, orms are pretty handy.

except is it? are most 0.1 module 'maintainers' responsible to the OP for high code quality, impeccable documentation and ease of integration?

If this post is a language gripe, then at least argue about language peculiarities, not the quality of the open source community's efforts. I would rather read a post arguing that the dream of py3k's never materialize (with examples) than a screed directed towards open source devs that just aren't doing enough.

I'm sure i'm missing some important context because some other folks liked this post, but it ends up coming off as entitled whining.

To summarize the author's gripes:

> Why are there modules in 2013 which aren’t pip’ed? > You don’t just drop version 0.1 and never care for it again. > I really want good documentation and examples.

talk about looking a gift horse in the mouth. there was an insightful post on here a while back about how repo-owners should give write access to (most) anyone that submits a pull request. That seems like a better solution than complaining about half-baked modules.

tip for the author: fork, update and pull request. Even if your changeset isn't accepted, it will probably help somebody in your position.

> I expect from a general purpose language a broad, general purpose range of useful modules. > I expect a certain pacemaking and modernity, a friendly competition between languages and interesting features.

the whole post is a series of moving goalposts. 'i hate perl because it's not java,' 'i hate js and ruby because they lack a comprehensive package database like perl,' 'i hate python because i have to manually run setup.py like a chump,' 'i hate perl because it's too complex,' 'i hate every js and ruby project because they don't have docs,' 'i hate java because it's stodgy and enterprisey'

Instead of looking at these as obstacles, why not approach any of these issues as opportunities instead? That seems like what happened with the python Requests module. The author complains about the lack of general purpose modules in npm (which, huh?) and then bemoans only having web frameworks to hack on.

i'll grant that sometimes it feels like everything sucks, but that doesn't mean we shouldn't do something about it.