nglevin

Another thought. Turn on the computer, turn it into something that frees you.

And if you want to be a little less selfish, make it something that frees more than just you.

(bye for now)

Good job, and I regret to hear that it seems you were given some bad advice from authority.

There's a lesson I learned at around 12 or so, good to learn sooner than later. Don't trust the experts, for the sake of being experts.

I probably have a few good burn out stories to share, but since this is a public forum and you're anonymous, let's just say that it's part of the experience. Learn, live, move on, towards something better.

nijk, I'd like to upvote your comment, but you've been hellbanned.

For those who can't see the dead;

"We have no need for 7 billion Einsteins. Humanity is a team project."

Context, sir!

We can't help if we aren't provided sufficient nouns and verbs.

Start with smaller projects, something simple based on either what you already know, or an existing lesson/blog/book. Then adjust it a little bit, work iteratively, towards the new stuff.

It's really easy to get lost in the big picture of what you want to do versus what you can do. Try not to do that. Just work on smaller bits involving the new stuff, falling back to what you already know at times, and keep at it. If there's a way you can do ColdFusion with Ruby/Python/whatever, go for it.

If you haven't seen it yet, Zed Shaw's Learn Code The Hard Way[1] series does a good job of getting you to use the right tools for the environment. Which is something I see frequently ignored by these sort of online lesson plans... it's not the languages themselves that are difficult to learn, but getting accustomed to the tools to use them, and the best practices.

[1] - http://learncodethehardway.org

I use -drawRect any time I need a UIView's CGContext. For everything else, I use -layoutSubviews.

When you do anything in Core Animation in -drawRect, that throws all drawing on CPU, instead of dividing the work between the CPU and GPU. Which, in one project where I was doing Core Animation alongside OpenGL, that had some very bad consequences.

Core Animation is pretty interesting. Internally, it does some drawing with Core Graphics, but that's only if you use certain features (i.e., use of CAShapeLayers, anything involving shadows)... and even then, CG is pretty darned fast.

I've found CAShapeLayers can be a bit of a resource hog, but since those resources tend to be thrown behind 60 fps animation, that might not be such a problem.

The CAShapeLayer issues only came up when I tried scrolling within a scroll view that contained a CAShapeLayer with a CGPath that had 20 points defining lines. Setting the CAShapeLayer to -shouldRasterize:YES after the animation completed "fixed" the issue, as long as you didn't need to scroll while the CAShapeLayer was animating.

(Don't even bother animating a CAShapeLayer while -shouldRasterize: is set to YES. That just causes even more fun problems with dropped frames.)

Keep calm. Reach out to people, old and new. Plan, and work towards a better tomorrow. Do not give in to fear.

Be sure to call your parents at least once a day. It makes a difference. And remember, the best way you can help others — especially family — is to help yourself.

I know that all may sound a bit trite, but it's how I tend to manage every personal crisis. I'm going through a significant rough patch, right now. Can't be paralyzed.

You may be in luck, sir or ma'am. It looks like the one man army behind Mobiruby found a copy;

https://github.com/mobiruby/BridgeSupport

Which he found from a really neat looking archive for popular open source projects, at that. Bookmarking.

http://code.metager.de/source/

Just made a few fixes to get the BridgeSupport framework to compile on 10.8. Might issue a pull request.

Which is what I meant by "within the bundle of your app." That may have been a bit too iOS developer-centric, I apologize.

In Foundation, [NSBundle mainBundle] returns a reference to an object representing your application's root directory, and the code and resources found within. Roughly the same bits that you'd find within an unpacked IAP file.

As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself.

You don't necessarily need BridgeSupport to call out to Objective-C.

Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame.

[1] - For example, http://merbist.com/2011/02/19/bridgesupport-build/ . The chapter referenced from O'Reilly's excellent MacRuby book does a better job of explaining the whole process.

That's fair. This does save one ugly, extra step that I didn't mention, which would be to call into the Objective-C runtime's C API [1] to dispatch messages and introspect Objective-C classes.

Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate.

[1] - https://developer.apple.com/library/ios/#documentation/Cocoa...

Functionally, this appears to be identical to JavaScriptCore's longstanding C bridge [1]. If Objective-C isn't your preference, there's nothing stopping you from calling into the C bridge from C++ or just plain C.

On iOS, developers have had to compile their own version of JavaScriptCore to use this API. That's the basis for HTML5 game engines like Impact [2], and some HTML5-to-Objective-C middleware platforms.

Unfortunately, until Apple says otherwise, this version of JSC is still subject to Apple's App Store review guidelines [3]. Thanks to guideline 2.8, you can't have your app, running JSC, execute any JavaScript that doesn't ship within the bundle of your app.

I'd like to see that rule change, someday. Exposing this Objective-C API in a future iOS release isn't going to change the status quo.

[1] - http://developer.apple.com/library/mac/#documentation/Carbon...

[2] - http://impactjs.com

[3] - https://developer.apple.com/appstore/guidelines.html

Just one nitpick for an excellent comment. GNUstep/Clang would be the only way to get support for array, dictionary and number literals, as well as ARC.

GNUstep/GCC is possible, but you lose support for all of the above, blocks, and several other recent additions to the Objective-C language.

That's a good observation, some inefficiencies are quite intentional. I didn't even know that about Linux until just the other night, when I was looking for non-GNU GPL projects that didn't require this process.

LWN.net has covered both sides of this subject quite well, in recent months, with the tedious process of relicensing VLC [1] and the GnuTLS copyright assignment controversy [2].

The politics of OSS make for some excellent reading.

[1] - https://lwn.net/Articles/525718/

[2] - https://lwn.net/Articles/529522/

Interesting. Do you have details on which jurisdictions do not allow this, and why?

I admit that I'm not familiar with international copyright law. I do know that several GNU projects, and other high profile open source projects, have a policy in place wherein contributors have to agree to a copyright assignment agreement before they can contribute their modifications.

If that's not possible in some regions, they clearly still have some means of continuing to uphold their own IP. I suspect it's not as harsh as completely avoiding contributions from some regions of the world. Unless I'm mistaken.

Ideally, a well-organized project would have a copyright assignment process to resolve those sorts of issues.

However, as far as I know you're right. If there's no clear authority as to who retains ownership and licensing rights to the code, and the contributions made to it, it's going to get messy.

It's possible, though it depends on the wishes of the original authors.

Stockfish Chess [1] is the one GPL v3 licensed app that I know of which has been available for... quite some time, now. I've seen several other Chess apps build on that engine, which go as far back as when I was just starting iOS development.

Now, VLC was the one case where one volunteer for the project invoked the GPL to get Apple to take an iOS port of the app off the store [2]. Based on that situation, it seems that if the original authors of a GPL licensed codebase want to pursue a claim against an app that uses that code, they can, and Apple will take it seriously.

I don't believe that situation has changed.

EDIT: For your own sake, it's probably best if you approach the original author to see if they can make an exemption, in writing, for the DRM situation. IANAL, but that seems like it would be the cleanest way to go about handling GPL licensed code without issue.

[1] - http://stockfishchess.org

[2] - http://www.tuaw.com/2011/01/08/vlc-app-removed-from-app-stor...

WindowMaker split off from the GNUstep project quite some time ago, IIRC. They don't even use Objective-C, they use their own framework for widgets built on WM called "WINGs."

There's still activity on the GNUstep front. Just a few things I can think of,

- Their runtime, libobjc2, has done a great job keeping pace with Clang and modern Objective-C. It now has a Cmake based build system and doesn't require any bootstrapping with GNUstep-make.

- GNUstep-base (the Foundation alternative) is solid, though some parts go back as far as OS X 10.6 and others OS X 10.4. You'll have to check the headers to see what's up to date. They do have an extremely capable implementation of distributed objects, last I heard they were planning to make it integrate with Apple's distributed objects implementation, but that project still seems to be pending.

- GNUstep-gui (AppKit alternative) just added support for 10.6's NSCollectionView very recently. Most activity there has been in the form of refinements. As I recall, drag and drop is still on their todo list... they really could use some manpower there.

- GNUstep-back (the backend renderer) still uses an API that's largely based on Display Postscript. They are planning to pitch a GSoC project to replace the Display Postscript API with one based on GNUstep-Opal (a Core Graphics alternative), and they already have a largely proof of concept Core Animation alternative running on it (GNUstep-QuartzCore.)

The project's current vision is to focus on making it easier to port Objective-C to other platforms, rather than to be a desktop environment. But like most small, mature open source projects, there's a lack of manpower keeping them from easily achieving those goals. Would be nice to see more activity there, in the future.

You can check out all of the projects I've named in the Github mirror at https://github.com/gnustep , but don't expect them to be responsive to pull requests. The mailing lists at http://gnustep.org/information/gethelp.html are strongly preferred.

As for the current website, I think Scott Stevenson designed it a decade ago long before he joined Apple. I like the design, personally, but I do understand that it's a bit difficult to navigate... and several of the docs haven't been updated in some time.

Is this the one?

http://nextstuff.info/mirrors/ftp.peak.org/next/apps/games/m... (tar.gz file)

> They need a vastly bigger space, or multiple conferences throughout the year, or a higher price, or something to manage the insane demand, if they actually want to improve this stuff.

Regarding multiple conferences, Apple decided not to do the Tech Talks for 2012. I hope they'll reconsider for 2013. That really was a great resource to have, and the 1:1 with the evangelists and DTS was excellent.

For higher prices, I keep on hearing this rumor and it never happens. There was a bump in the prices around 2010, and it never went further up from there. Maybe they're afraid of pricing out the indie developers? I have no idea.

I believe that's true, regarding Developer Relations. I did get into a Tech Talk one year that was sold out through a large media company, thanks to that.

However, that's a tricky road to go down. I have no idea what Apple's criteria is for that, and I know some teams that have worked closely with Apple in the past that never got that treatment.

Back in 2011, there was one guy who waited a few minutes before deciding to purchase, checked the site again minutes later. Then Apple gave the "we're all sold out" message.

He goes to check the Apple Store. It still says that there's something in his shopping cart. So, on a whim, he decides to complete the checkout process. Put in his address, name, info, credit card, clicked through a few screens.

And he got in. All thanks to a cookie.

Alas, it doesn't seem like 2013 will have any "saved by a cookie" moments.

Moscone North alone would be an improvement from Moscone West. Heck, just take over all of Moscone for the week!

I've been told the reason the event has been kept small is to maintain the same ratio of Apple developers to attendees. But I think that overstates the value of the Apple devs a bit. The attendees at this event really are one of a kind.

Well, every year's a full house. It used to be a great event where you could meet people in IT, web developers, Objective-C developers, Mac developers and iOS developers. Now, it's pretty skewed towards iOS development, but it's still fun.

I think it's absolutely worth it to meet the Apple community. You'll get a pretty interesting sampling of people who are really enthusiastic about developing for the platform, including members of the Mac press and some folks who are just trying to learn things. And you won't find a better group anywhere else.

As for the labs, I've had a mixed experience with them. Some teams are really approachable (the Accelerate team, awesome guys), some not so much. I've heard some very funny stories from some of my friends and from people I respect regarding the labs for the App Store review team... I don't know if Apple has App Store labs anymore. Wouldn't be surprised if they went away.

Regarding food; Moscone West's lunches have always been kinda suspect. For some reason, food quality tends to go down quite a bit as the week goes on. Consider eating at the Metreon or Mel's instead for a quick burger for a protein boost. The WWDC bash more than makes up for the rest.

Not going this year, pursuing other interests at the moment.

As I recall, this shop was run by Eric Shepherd up until 2011 [1] before he transferred control to Tony Diaz.

Shepherd is an author of many fine Apple II and Apple IIgs apps, including the excellent IIgs emulator Sweet16 [2]. Now, he's a technical writer for Mozilla. Awesome guy.

Diaz... runs Apple2.org [3], and I'm ashamed to admit I'm not aware of anything else he's done for that community. If anybody else could fill in, feel free.

[1] - http://a2central.com/3234/syndicomm-changes-management-maint...

[2] - http://www.sheppyware.net/software-mac/sweet16/

[3] - http://apple2.org

Yes, bitrot is _addressed_, but not resolved.

That's the source of my frustration whenever the open source solution is brought up. It only works when there are hands present to maintain the source.

Which is much more effort than, say, writing a book and leaving it some place to be rediscovered. Only the popular or the intensely niche seem to survive.

It may be old news to you, but Kai Krause's "Software is merely a Performance Art"[1] treads much the same territory, framing software as an ongoing framework to influence future generations.

Open source can be a solution, but it's limited by bitrot; what it runs on, and who or what is capable of interpreting it.

I feel there needs to be something else, haven't quite found out what that might be.

[1] - http://www.edge.org/response-detail/10113