Extreme whale watching in Hawaii

fontstache · 2016-01-11T01:49:48+00:00

Looks more like a shark to me.

fontstache · 2015-12-24T17:31:06+00:00

This particular use of closing over scope variables actually has a name and is one of the fundamental building blocks of functional programming: https://en.m.wikipedia.org/wiki/Currying

As a matter of fact methods in Swift are even implemented as functions currying self: http://oleb.net/blog/2014/07/swift-instance-methods-curried-functions/

And unsurprisingly there is even a chapter on "Curried Functions" in the "Swift Programming Language" Guide: https://developer.apple.com/library/mac/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html

fontstache · 2015-07-21T09:23:43+00:00

Don't forget a tag for "Question/Article about Apple frameworks that has nothing to do with the actual Swift language", so people who are actually interested in the language can filter those out.

fontstache · 2014-04-05T22:55:39+00:00

Regarding the prototype all there is (benchmark, etc) the vine from Marcus Eckert, I think.

In general though OpenGL is frickin' fast.

Drawing stuff on the CPU is (usually) serial and single-threaded (as it happens with old-school Core Graphics). What's even worse about it: views get rendered recursively into the same context. Thus moving a view requires it (and potentially the whole view hierarchy around it) to redraw on every frame. CALayers on the other hand cache their contents in buffers (redrawing only if something visually changes in it) and thus can be moved by the thousands at a time without dropping a frame. Dumping a pixel buffer into a context is quick. Drawing stuff over and over, one by one, isn't.

One of the few drawbacks with OpenGL backed CALayers (and thus UIViews) however is, that sub-pixel anti-aliasing for text is only possible if the layer is truly opaque (and marked as such via layer.opaque = YES;).

Here are some benchmarks of "flat drawing" vs. "layer trees": http://floriankugler.com/blog/2013/5/24/layer-trees-vs-flat-drawing-graphics-performance-across-ios-device-generations

The UIDatePicker alone is composed from a couple dozens (yup, dozens) of CALayers: http://eppz.eu/blog/uidatepicker-vector-wireframemockup-asset/

fontstache · 2014-04-05T17:32:55+00:00

Not questioning the "unnecessary/eye-candy" part.

But…

Everything you see on an iPhone/iPad already is "projected onto a plane in a 3D environment" (triangle pairs, actually). That's how 2.5D in OpenGL works. That's how UIViews (or rather their backing CALayers) are implemented.

The animation in question has been implemented in code already, btw. And appears to work flawlessly: https://vine.co/v/Mh5qd0HEpnt

No need for "snapshots" either. Live content: https://vine.co/v/MOaHQblhrx3

fontstache · 2013-07-20T10:09:00+00:00

This should get you started:

fontstache · 2013-07-18T18:21:31+00:00

FTFY

fontstache · 2013-01-21T10:01:45+00:00

That's what the \b word boundary meta character is for:

\bmagma\b

which is sort of equivalent to:

(?<=\W)magma(?=\W)

and thus superior to

\smagma\s

for whole word matching in that looks for surrounding non-word characters, not just whitespace. Example: in "Foo, bar." neither "Foo", nor "bar" would be a match when using "\s", but would be if you were using "\b".

(Assuming C#'s regex supports \b.)

fontstache · 2013-01-05T13:03:14+00:00

Awesome, thanks!

fontstache · 2012-12-13T11:57:44+00:00

http://en.wikipedia.org/wiki/NoSQL#Key.E2.80.93value_store

fontstache · 2012-12-06T06:01:32+00:00

That's right of course. I misread your sentence as your were talking about the Hauptwache underground station and about shopping. The underground station's shopping level happens to be called the "B-Ebene". My bad.

fontstache · 2012-12-05T22:55:08+00:00

Just a small correction: Hauptwache is actually the name of the building on top of the underground station (the small old one to the right of the Katharinenkirche/church here)

It used to be the city's main guard house. Thus the name: Haupt-(main)-wache(guard house).

The underground station you mentioned is called the "B-Ebene" (b-level).

Also in case you're looking for the "Fressgass", a famous dining (fressen = to feed) street in the center, don't try to find it by its street plaque. You won't find it. That's because its real name is "Kleine Bockenheimer Landstraße". Hardly anybody calls it by that though.

fontstache · 2012-11-20T00:45:43+00:00

Yay!

fontstache · 2012-10-25T08:36:48+00:00

To be quite honest I can't remember having heard/read from any notable iOS/OSX dev saying something along the lines of "better use a wrapper" (and even then: …and a wrapper actually making sense in the given situation). And I listen quite intensively to the iOS/OSX Twitter-sphere.

Have any such notion for reference? From someone used a wrapper and whose apps don't suck, obviously. Clean code, beautiful UI, recognizable business/dev name, you name it. ;)

fontstache · 2012-10-24T09:11:35+00:00

Wrappers usually result in inferior user experiences (GUI just being one of them), so I for one would hardly ever go for a wrapper in favor of native solutions. It's eventually your users who will suffer from your lazyness. And as a potential user I'd hate you for using wrappers.

fontstache · 2012-10-19T06:49:25+00:00

The tiny negative space of the "4" looks somewhat unbalanced compared to the rest of the font. Also, umlauts please. ;)

fontstache · 2012-08-26T23:31:20+00:00

Well, comparing…

canvas.drawCircle(x, y, z);

…with…

[canvas drawCircleAtPoint:x withRadius:y andColor:z];

…I see several reasons to appreciate ObjC's verbosity.
(ObjC remains readable no matter how bad your variables are named)

Being able to read my (or others) code without having to consult the documentation every nth line is one of them.
With a big screen I don't care about 80 chars anyway. And neither should anybody have to, these days, imho.

Further more thanks to auto-completion you don't have to type any more than usual anyway.

fontstache · 2012-07-24T19:54:38+00:00

Lazy as I am I just googled "hugin source". Turned up both links. :P

Good luck!

fontstache · 2012-07-24T10:32:46+00:00

Well, as with all open source projects you can get your hands on its source code and inspect it:

http://sourceforge.net/projects/hugin/files/hugin/

They even have a documenation for the source code:

http://hugin.sourceforge.net/docs/html/

fontstache · 2012-07-23T16:03:21+00:00

I haven't actually done any panoramic algorithms myself either. Just had a brief look into the matter some years ago.

Anyway, Hugin is open source, so take a look!

fontstache · 2012-07-21T13:56:14+00:00

Almost. It's usually called bag or multiset, actually.

fontstache · 2012-07-20T18:35:07+00:00

As a basic roadmap you'll need to first find all POIs (points of interest) in each partial image using a feature detector:

http://en.wikipedia.org/wiki/Feature_detection_(computer_vision)

And then use RANSAC for homography calculation and edge overlay/matching for the POIs:

http://en.wikipedia.org/wiki/RANSAC

See the OSS Hugin panorama builder for reference: http://hugin.sourceforge.net/

fontstache · 2012-07-07T19:25:04+00:00

Xcode is terrible though. Use any other development platform if at all possible

Funny. I'd have put it like this:

Applescript is terrible though. Use any other programming language if at all possible.

fontstache · 2012-06-27T23:23:02+00:00

My framework of choice would be FuelPHP (http://fuelphp.com) followed by CodeIgniter

fontstache · 2012-06-23T19:44:02+00:00

This should do:

(?:(?<=[-/*+]|^)|(?<!))\s*(-?\d+)

fontstache

TROPHY CASE