fieldforceapp

Dear Apple, thanks for keeping the same display dimensions as the iPad -- I was actually starting to sweat about the prospect of having to do more AutoLayout work!

> Aren't any other good options for printing a single PCB

Bay Area Circuits, free layout tools & plenty of short run cheap boards starting at $30 (!) and up: http://bayareacircuits.com

Nivi, great idea -- thanks! The fine print says WSGR will help (for free?) if the startup is "qualified," what can you tell us about their qualification process?

Good story, thanks for sharing.

Would you mind telling us how your IAP is working out for Groups: did anyone buy the "I really love your app!" option at $9.99 -- cool idea, btw.

I'm curious about what you think is still a viable way to compete with GoPro: is it only on price, or are there some missing features that a potential competitor exploit -- the UI/UX you mention? If RED comes out with a water-proof camera I guess that takes care of the high-end, so is the only way to compete with GoPro to go... low end?

> Can you be more specific about monetization links?

I don't mean to confuse this with a license type... we get about a 30 referrals a week from your site (nice traffic for a control!) and just wondering if we can direct them somehow to try the app which actually uses the control. Does Apple have an app store affiliate program? Maybe you can leverage that somehow?

> When the repo is first added to Cocoa Controls, a field is filled out for specifying which licenses the control is made available under

Can this be updated, manually?

You're doing good stuff, although sometimes we have trouble keeping up with the demands from developers; any thoughts on adding "monetization" links? (Guess we could do this in our GitHub readme too...)

By the way, how are you determining license type? What exactly are you scraping on GitHub to determine this? http://www.cocoacontrols.com/platforms/ios/controls/openspri...

Liked your idea and will follow your developments on GitHub with an eye towards how you're going to integrate a CoreData client-side library. Besides the front-end issues you highlight, a key challenge will be synchronization: unless you don't plan to allow your users to work offline?

I agree with your hope that Rails could somehow be extended to cover this mobile use case, wish I had the chops to create a Devise+MobileAPI generator with a iOS native MongoDB-sychro engine. (Can Rails generators synthesize ObjectiveC source code?)

By the way, every time I think about doing something about this I keep an eye on the folks at Parse.com: seems like every week they're solving more and more of the backend part of this problem. And they're working on front-end libraries as well...

was I the only one confused by the name... http://www.deadmau5.com

Sorry for the cross post... Glass was the "one more thing..." moment for sure; heard that there was a long line to purchase them for $1500 per -- any comments from any new HN owners?

Met with GOOG employees today who were testing newer versions, better resolution & new comms. I wasn't allowed to wear it but it looks bulkier than I imagined.

The odd thing is, during a meeting with an employee who was wearing Glass, it was hard to figure out where to focus my eyes on their face -- it was like talking to someone with a lazy eye. Made me especially self-conscious: felt like I was being rude, and my rude act was being filmed using the Glass!

Glass was the "one more thing..." moment for sure; heard that there was a long line to purchase them for $1500 per -- any comments from HN owners?

Met with GOOG employees today who were testing newer versions, better resolution & new comms. I wasn't allowed to wear it but it looks bulkier than I imagined.

The odd thing is, during a meeting with an employee who was wearing Glass, it was hard to figure out where to focus my eyes on their face -- it was like talking to someone with a lazy eye.

How would this compare to say the BitNami RubyStack, I've been using this to keep multiple Rails version (2.x and 3.x) running on Lion:

http://bitnami.org

Agree with the focus on quality of communication, but is the issue here self-inflicted? Is Everyme trying to solve a problem created because too many of us "friended" their co-workers?

  5) IOS4 vs IOS5. Come on Apple, I am begging you to not
  turn IOS into the next Internet Explorer.

I don't see how you can avoid this and without incurring the fragmentation you find in Android. We should expect Apple to continue with the measured iOS migration and sometimes not so subtle push to get us devs to move the bar forward. Interesting to see how Mountain Lion will force a move to XCode 4.4 (my guess) and Apple will bury the older SDK's ever deeper in their website.

I really can't fault Apple for this approach.

BTW, we rely on Flurry data to judge what the economic cost of choosing a new iOS target.

How would this compare to say the BitNami RubyStack:

http://bitnami.org

@aaronpk we're currently looking at geoloqi but would you mind clarifying the benefits of using your service over iOS CLLocationManager calls? Specifically, have you analyzed the relative power consumption & accuracy of various CLLocationManager settings?

For example, we found the best power consumption when the desiredAccuracy value is set to kCLLocationAccuracyThreeKilometers, and we trigger the startMonitoringSignificantLocationChanges method before entering into the background. Surprisingly, the accuracy was much better than 3km but varied depending on device & OS. Similarly, the power consumption was affected by the background network access schemes & buffering we used, of course.

Anyway, we stopped our studies after sampling just a few devices (3GS, 4) and one or two OS releases (iOS 4.2 and 5.0). Don't mean to pry your secret sauce, but what type of calibration are you offering?

Thanks!

Perhaps this technical post from AT&T labs (http://bit.ly/zFyXTw) discussing their work with Pandora to optimize power & bandwidth consumption might shed some light on AT&T's thinking. It might be a win-win for AT&T to partner with such app producers, optimize their network utilization in exchange for some end user subsidy -- extending the subsidy carriers give to device manufactures to the app developers, essentially?

Good work... and from all of us Japanese language students, thanks! I wanted to amplify the comments from @politikus with some additional observations:

- market to children, or really to parents trying to teach their children Japanese (like me!) - market to young students, themselves, not their parents

The above two user groups may be mutually exclusive. In either way, I would highly recommend you translate your app into Japanese. It's your biggest market, no?

The SRS/SM-2 algorithm you're using might need some tweaking to support leaderboard & scoring like @politkus mentions -- thinking about kids, they love to compete. I would recommend moving more towards more gamification.

Harder to do on Android(1) than iOS, but I would recommend using IAP for additional lessons. With kids, the goal you're shooting for is to have the kids bug their parents to buy more levels (!) or the older kids to brag to their friends.

And finally, why not use Parse.com instead of SyncAdapter? It would give you both an easier path towards iOS as well as potentially a web based dashboard, etc?

Gambatte kudasai!

(1) My opinion only, of course, I'd like to learn more about in-app purchase options on Android.

Don't want to discourage you guys, but coming from an EDA background myself, you didn't answer the question: > What's the advantage over gEDA, gHDL or similar?

I think your answer is, "we're focused on design & community." But I wonder if you might reconsider yourselves the "Codecademy of hardware" instead?

>7M+ pounds of weight have been lost by website enabled users (Estimated ~18M pounds lost across all users)

Perhaps the best stat I've ever seen on a mission statement, more fat... I mean power to you!

FWIW, the iOS5 based Storyboard has been helpful to get around some of the issues you mentioned; we just finished an app, granted with a very limited number of screens, but Storyboard was a time save for sure. Details, here: http://blog.fieldforceapp.com/weekend-project-ios5-storyboar...

As an investor, I'm long TSLA & as a human I have to be bullish on this company. It's easy to root for them, but I really hope they get the roll-out of the Model S correct & focus on the customer, not the tech, damn it.

For those of you old enough to understand the joke, I don't think Elon will be trying to buy Cocaine anytime soon, but I'm worried about the next phase after the first round of sales to the enthusiasts like... us. http://en.wikipedia.org/wiki/DeLorean_Motor_Company

In the hopes that Elon and the boys are paying attention, some things that bugged me from the plans so far & from the "butt test" I gave the Model S:

1. The options look great and I'm excited, but help me complete these sentence... "I've owned the Model S now for more than a year and I'm never worried about getting serviced because Tesla Co. will..." what?

2. Tell my mother, or anyone not in your core market, why they need this car & what role it plays in their life vs. buying a gas powered (or for extra points a Hybrid) car.

3. Tell them exactly what's required to put a charger in their garage and how much that will cost; better yet, help them do it (for a fee!) and partner with some other Green tech folks to make a house call and split the costs -- solar panel resellers for example?

4. Nit picking, but man was that 17-inch screen big! Couldn't we save some money a go with a 12-inch and a couple of physical (user programmable) buttons instead?

5. Listen, I'm a large man, where's my "oh shit handle?" http://www.urbandictionary.com/define.php?term=oh%20shit%20h...

(And in case you missed it, I'm long TSLA & rooting for you all the way!!)

MMI has been shifting away from proprietary app and comms processors for a number of years and this is a a continuation of Jha's policies. This news is more of a loss for QCOM as they were certainly hoping to have an "in" with Jha to possibly displace TXN parts on Motorola devices.

INTC isn't done with Medfield, of course, you should expect more cores & and aggressive push on process nodes. I would consider it is a validation for their new mobile strategy: http://www.intc.com/releasedetail.cfm?ReleaseID=559064

And as to your point about ARM-based devices being more "innovative," to some extent all the ARM-based devices are basic shared-memory architecture with the same mix of IMG GPU's as Medfield. You could argue, conversely, that Intel is at least trying to innovate on their pipeline and memory architecture (an increase the L2 cache for example) which the ARM-based SOC's are not doing.

Of course I guess this just means you'll see ARM A15 designs coming to market sooner in an attempt to separate from Medfield?

That's correct. If you remember, Tim Cook described this limits on PPC based products as a "thermal problem" which is what drove them towards Intel. Presumably, ARM's licenses don't have this problem, in part, as @rbanffy implies, because the ARM architecture doesn't rely on a single source as the PPC did.

I was an early contributor to Cocos2d, Riq was always looking for a good level editor and produced his own eventually (http://www.sapusmedia.com/levelsvg/) but it was a bit limited. I'm sure he'd be interested in your work, have you reached out to him?

Knowing nothing about Fireworks, in what language did write the plugin?

Forget technology, go see some art.

And like @jack said, buy some local artisan goods.

I don't know, ask Gopal. But it will be interesting to see if SFDC does anything truly disruptive in this space. Hard to see how shareholders are getting much value from a task manager behind an expensive two-letter domain name!

Sure Marc's got deep pockets, but is there any organic growth here?

I think these guys ripped us off, and all they did was go after the low-handing fruit: tasks only. We pushed to add geo-tagging, voice, business card scanning, and some a peer-to-peer CRM system.

Plus, we have a cooler name: http://fieldforceapp.com

I guess we shouldn't expect Salesforce to cannibalize themselves with a mobile CRM solution, but still they could have tried a little harder!

Would like to point iOS developers to the excellent cocoacontrols.com for these and other projects, and a shameless plug for our Apple "SpringBoard" clone:

http://cocoacontrols.com/platforms/ios/controls/openspringbo...

Nice post. My time at Panasonic & then later selling software tools to the Symbian OS developers was eye opening to say the least. The Japanese corporate mentality was, in many ways, still feudal. Fujitsu's Symbian OS team was given a lot of support by NTT Docomo but also a crushing amount of responsibility -- they were developing something like 30 baseports a year, 15 each for the Spring and Fall seasons, for all their handsets and acting as lead Symbian developer for the entire NTT Docomo group with little to show for it. Talk about churn & burn.

When I spoke to the management about this, they said that they were in a position where they couldn't say no to Docomo and likewise they didn't see anyway of not continuing to do their development. And yet, and no offense to the folks grinding this stuff out, there was little real differentiation in the software, the OEM's were all focusing on the hardware feature differentiation and the software was really just a "necessary evil."

So I'm not convinced that it's simply a case of needing a "force multiplier" framework, the Japanese companies need to see that there's value in cultivating better, highly differentiated software.

DeNA, GREE, and the other Japanese social startups seem to have found this whereas the larger vertically integrated semi manufacturers are basically stuck writing drivers for their whizzbang hardware.