I think ORMs are there to make developing easier - but doesn't obviate the need for the user to understand how the underlying database works. For one based on my understanding of their use-case, could've used a validation :on => :create only. Likewise, if case-insensitivity is needed, they can enforce that on record insertion or, if they're using something else like MySQL, just use case insensitive collation. The fact that I know how to write SQL doesn't mean it's always easier/faster/better than using an ORM...
> I think ORMs are there to make developing easier
Only for object oriented apps, where you want to tightly link behavior to your objects. For other kinds of app architectures, there may be no relational/object oriented mismatch to smooth out.
neat! i was just looking at the dreamscreen a few days ago (https://www.touchofmodern.com/sales/dreamscreen/dreamscreen?...) but the lightpack2 looks even more elegant/smooth in the way it reacts. it even has the "pixels" that add an interesting element...
We are a start-up located in San Francisco that curates modern designed products for 5-day sales for our members. Our goal is to help people discover unique and beautifully designed products while getting them at a great price. The site is growing extremely rapidly, adding thousands of users daily and dozens of design/manufacturing partners each week. The company is early-stage and VC-funded, looking to bring on sharp, hardworking talent with competitive salary. You'll have a chance to work directly with the founders and be part of the core team.
EXPERIENCE YOU SHOULD HAVE
+ this is not your first gig
+ you have experience with building end-to-end products
+ you are an expert in rails, jQuery, objective-c and MySQL
+ are experienced in scaling rails (1M+ visitors/month) and building on the android platform
WHAT YOU'LL BE DOING
+ working across all channels including web, iPhone, iPad and android
+ driving operational efficiencies including fraud detection, logistics automation, advertising integration, improving metrics measurements, bug fixes, etc.
+ creating new features as the company grows including scaling the code base, a/b testing, writing integration tests, setting up search servers, personalization, etc.
+ communicating directly with the CTO daily
If you fit the bill, please apply with:
+ resume highlighting what you've been up to the past couple of years
+ cover letter explaining why you're interested in e-commerce
Use Subject Line "ToMo Senior Developer"
Send your application to Steven at engineering-jobs@touchofmodern.com
Yeah I work for a daily email site and we do this too. We just don't send another email letting them know - that's more spam! I was surprised that this was considered newsworthy... Most people in the industry do this. It's definitely considered best-practice - it reduces costs, improves metrics, and probably doesn't subtract much value compared how much it costs to keep sending them emails.
You'd be surprised at how little most startup focused journalists know about the day to day of the industry. If it hasn't been touted in a press release or mentioned at an investors conference they probably don't know about it.
I completely agree. I woke up to some crazy long page rendering time on NewRelic and couldn't figure out what was going on... until I saw the huge backlog of mixpanel events on my db. Not only is it making page rendering slow, even worse, it's tying up my background workers for 30 seconds at a time, causing a huge backlog on ALL my background tasks.
Exactly the same sentiment. That's the reason we did not launch with an Android version today. We will probably write it natively when the time comes. Titanium has proven to be a nightmare with Android.
Boy, do I feel you there. I've been working with Titanium since last March and I've yet to develop some semblance of a cross-platform application. It's a bloody mess in there.
Hi, I'm the CTO for RAVN. When we decided to jump into the mobile dev game no one in our company had any experience with Object C or Android dev. We knew we wanted an iPhone app for sure, and probably an Android app eventually. I had taken a brief look at Objective C previously, and coming from Ruby/Rails, it looked less than trivial (memory management?! I hadn't done that in 10 years). I had heard about frameworks that would allow us to use JavaScript to write our app, and also allow for cross-platform development, so I started researching.
I looked at PhoneGap and Titanium primarily. We ended up going with Titanium for a few reasons:
- As you may or may not know, PhoneGap works by creating a sort of Safari "wrapper" that lets you write your app in HTML5 and JS. But the performance is crappy relative to native rendering. Titanium also used to work the same way, but more recently it actually compiles code written in JavaScript to native Obj C and Java. Clearly the benefit is speed.
- Even though Titanium only supports iOS and Android, we didn't really plan on ever developing for other platforms (e.g. Windows Phone, BlackBerry, webOS).
If you're looking into developing a mobile app, I would recommend taking a look at Titanium. To be fair, I had to write a little Obj C to hack geofencing functionality into Titanium (if you're interested in that: http://stevenou.com/post/17623116547/how-to-hack-geofencing-...).
There were lots of pros and cons to using Titanium and I'd be happy to answer any questions.
It's been 4 or 5 months since I switched from Titanium to writing native Objective C myself, so things may have changed since then (but I don't think they have). It's a misnomer to say that Titanium "compiles" Javascript to Objective C.
Titanium lets you write Javascript that executes using JavascriptCore (a Javascript processor that is part of iOS) on iOS, and I believe V8 on Android, but I could be wrong on that. Then, they have bindings in Objective C (and Java). So when you call in Javascript Titanium.window.create();, the relevant Objective C is executed by the bridge.
This is all fine and dandy until you start doing something more complicated than displaying a few windows. For example, our app needed to have some complicated TableViews with highly customized rows that needed to be re-generated on each draw. Executing the logic for that in Javascript has a huge penalty hit.
So while I would recommend Titanium over PhoneGap any day, it is not true that it is a "compiled to Objective C" sort of thing (again, at least it wasn't 4 months ago, and I was using at that time 1.80 which was the super-bleeding-edge-dev build, because I had a ton of issues with random crashes in the 1.7x series due to the Titanium Database module not being completely thread-safe at the time).
Sorry to hijack.
EDIT: Just to confirm, 1.81 is the current "stable" release, so what I was using 4 or 5 months ago is what is the standard now. So it does not compile Javascript to Obj. C.
A lot has been fixed in the 1.8x series, but at the end of the day you're still depending on someone else's middleware to behave and not crash your app for no reason.
In case anyone decides to go down the learning Objective C route, learning with the excellent "Programming iOS 4" book took me about 1 month from the first page I read to having the whole app re-written, so it's really not too terrible. You don't have to do any of the memory management stuff anymore with iOS 5 and ARC, either.
A lot has changed in the 1.8 release, and I'm sorry to hear you ran into problems with earlier versions. Our abstraction layer can be a bit "magical" sometimes, and we need to do a better job communicating the tips and best practices that we've learned from our major apps, such as the NBC flagship iPad and mobile apps, and the Jimmy Fallon apps. We've actually been releasing a lot of content on manual memory management and app structures lately, which we hope will be helpful in this. That content is on our dev blog and wiki.appcelerator.org
In terms of the bugs I am hearing about, that really sucks on our part. If youre using Titanium and run into an issue that's really giving you trouble, my team monitors messages to community@appcelerator.com - we're out in the dev forums as much as we can but questions do go unanswered sometimes. Please let us know if your question does.
All that said, we've had over 30k apps (that we know of) shipped to the stores, the best of which stack up very well against their native-only counterparts. We have work left to do to make Titanium bulletproof but we think we're headed in the right direction.
Titanium was a nightmare. The edit-compile-debug cycle is so slow. I ran back to ObjC after two weeks. Development is faster and the resulting apps are better.
It has good points too but for me it was a net negative. You couldn't insert rows into a table view without it crashing, you had to reload the entire thing (that was in May).
I'm amazed at the results some people get with Titanium. Maybe I was doing something wrong, but I'm very familiar with web dev and found it intolerable.
One trick that really helped with the edit-compile-debug cycle, especially on iOS, was to run the app from the command line instead of using Titanium Studio. I set up a Rake task that would run the app and then listen for a timestamp change to tmp/restart.txt, at which point it would restart the app within seconds. I already had a vim command for touching that file (it's used by Passenger for a similar purpose) so all I do while developing is press a key combination and wait for the simulator to pop back up. Very fast.
The patterns and frameworks I use in single-page javascript apps carried over well to developing with Titanium, including tools such as Backbone and CommonJS. Titanium supports CommonJS directly now but it wasn't available when I started so I used Stitch to combine the code into a single javascript file and have been happy with the result. One bonus of using this approach is that I've been able to share a large portion of the code with the mobile web version of the app currently in development (using Backbone and jQuery Mobile).
While we ran into some problems that were difficult to track down, the code for Titanium is on GitHub and is easy to fork if you need to. For example, one thing that's prevented me from posting a link to this app previously is that the Android version (also built with Titanium) is experiencing frequent crashes on certain devices. After several (ok, 20+) hours of debugging I discovered that the problem was in the 'click' event handler on table rows -- the handler was passing the whole table row object in the event handler and was causing occasional crashes due to the size of that object. I didn't need that data to be passed in the events so I just commented out that portion of Titanium code and everything's great now (we're releasing an update shortly). Sure, it was a brutal bug to find, but the source was available and not too difficult to follow.
The app also includes custom modules written in Objective C for iOS and Java for Android, but only for very specific functionality that wasn't already included in Titanium -- 99% of what we needed was already available.
If there's any interest I'm thinking of extracting my pattern into a basic application that I can share with others and perhaps build a bit of a framework around it. Here's a gist as an example of code used in the app: https://gist.github.com/1832639
That's true. It doesn't exactly "compile to Objective C." But it's an easy way for people to understand the basic concept. The performance is much closer to full native than full HTML5.
Yeah, I figured. Just wanted to say something since a person or two was saying that they were surprised it compiled to Objective C. Congrats on getting your app out the door -- at the end of the day, every product has different needs, and shipping a quality app that fits your customer's needs is the most important thing.
A friend recommended your app to me a few days back, and here's my impressions.
At first glance, the UI looks great, but it doesn't feel right. The big one for me was how I must start a swipe from the picture of the event, not the edge of the screen or the bottom portion with the profile pictures. The UI looks and acts almost like a scroll view, but not really.
Going into an event's View Details view, there are items in a table I can tap to view more details, such as See Full Description. Native iOS behavior is tapping will drill down immediately, and things can load slower if needed. It seems like there's a bit of a delay between a tap (when the table item flashes) and when the drill down happens. This time varies seemingly randomly, and can be up to a few seconds. It makes me wonder if the tap actually registered, even if it does flash.
The idea for the app is great, but I stopped using the app at that point because it's frustrating to have to change habits formed from using pretty much all the other apps on iOS. It's something to consider when thinking about using some non-native framework, especially for something like iOS where apps generally follow a set of human interface guidelines, as any difference in behavior can stand out like a sore thumb to users.
Is this something that you guys noticed or thought about internally during development?
I have to say I had not noticed the first issue. But now that you mention it I guess it's true.
The second issue is something I have noticed occasionally. I guess I'm always testing on WiFi so it tends to load quickly enough that I never considered it problematic. Definitely worth taking a look to improve the usability there.
We tried to follow iOS design conventions as much as we could, but I guess we haven't quite nailed it yet!
Been using Titanium for a little over a year on an app for our company. By all definitions our app is very simple - a login form, tableviews that drill down two levels and webview.
Our customers like the app and it works great, does exactly what it's supposed to do. iPhone development seems to go pretty smoothly. Debugging is fast. On Android it's a nightmare. The emulator is so slow to launch for one thing. It reminds me of developing a site and then when you're all done, testing it on IE6 and, surprise, nothing works! That's been my experience anyway.
The app seems to be great, but unfortunately I'm hesitant to find out since it requires Facebook to do anything. I really don't want an app to be posting my activities on my Facebook wall - Maybe there's a choice in the app, but I can't really tell.
So, until you guys figure out a way to make the app functional without me having to connect it to my Facebook account, I'll just have to give it a pass.
Do you guys realize that webOS apps are written in web languages (HTML, CSS, Javascript) so it would not be very difficult to port your app to webOS.
More than that, if you write it in webOS' Enyo framework and use Phonegap you could have your app ready for iOS, Android, webOS, Blackberry, Chrome Web App Store, and the MacOS app store very fast and easily.
Whoa, didn't know Titanium compiles javascript into native code. Cool! But Phonegap has a pretty rich set of plugins and its relatively painless to extend Phonegap's functionality with a plugin. Did you have to hack in your geofencing capability? There's no plugin framework?
No, Titanium doesn't compile to native code. He's using that as shorthand for "Titanium uses JavaScriptCore to implement a bridge that lets your JavaScript call native code". Your JavaScript remains interpreted (and will not be JIT compiled, as in Safari, since your app won't have the JIT entitlement) but in my testing of JSCore it's not generally a bottleneck.
There is a module framework, but since the Titanium framework already created a CLLocationManagerDelegate in their GeolocationModule, I didn't see a clean way of adding geofencing in a separate module. So I hacked it right into the existing GeolocationModule. Again, the performance difference between native code and rendering HTML5 is huge, and that's why we decided against PhoneGap. Personally, if HTML5 wrappers were the only option, I probably would've just sucked it up and went native Obj C. Like someone else mentioned, there are a lot of challenges to making an HTML5 app perform like a native one.
Speed is not the only benefit of Titanium. I recently submitted a phonegap app it was rejected on the basis that "It would be appropriate to add iOS specific UI and functionality". I am pretty pissed-off. You made the right choice.
Tiny feedback: Your homepage renders incorrectly for me on Chrome 17/OSX. The screenshots which are lined up to cycle on the phone display bleed through vertically all the way down the page.
To add to this (Chrome / OSX), clicking on the 4 buttons on the left side multiple times breaks the scrolling. The more you click it, the longer it breaks. I noticed this exact same bug on that stop SOPA banner (featured on HN about a month ago) which also caused a page scroll when clicked. I wonder if the issues are related?
The app looks great, thanks for sharing. Did you guys come across any issues with Titanium's memory management? I'd imagine debugging could be a nightmare.
I haven't used SimpleGEO so I couldn't really say. Appcelerator Titanium just provides API functions to access native geo features like GPS. It also provides reverse and forward geocode functions but I found those buggy so I implemented my own using Google. I know Appcelerator recently acquired Cocoafish, which I imagine will provide much more comprehensive geo features for future Appcelerator devs.
Top drawbacks:
- Bugs/memory leaks. Since Titanium does memory management for you, you will occasionally run into memory leaks or bugs that don't make any sense, and there's not much you can do about it. Appcelerator isn't the fastest at releasing fixes either.
- Using third-party SDKs is generally annoying. Want to integrate Tapjoy? Chances are you'll need to write a custom Titanium module. Same goes for just about every single SDK out there. You have to manually create the JS->Obj C interface (aka module). There is a Titanium marketplace where you can buy existing modules for relatively cheap, but it's only a handful of very popular SDKs, like TestFlight, Flurry, or Urban Airship.
- Need to manually integrate new iOS features. Like geofencing, for example, I had to manually hack into the framework, so you're always a step behind in terms of the latest iOS features. That's OK for most people but when you do need a feature that hasn't made it into the framework, it can be annoying.
We didn't specifically look at appMobi, but as far as I know Titanium is the only (relatively mature) framework that compiles to native Obj C, and is not just a wrapper for HTML5. The performance difference is enormous.
To be honest I've only built games and in that sense appMobi has an edge with their DirectCanvas technlogy which speeds up the canvas rendering on mobile devices by 500% (according to them). I guess you don't use any canvas though so not really relevant in your case.
Thanks for the reply anyway. I will definitely have a closer look at Titanium.
If you're making cross-platform games, you may want to take a look at playn, we have been using it for over 5 months, and it has been really easy to use and works really good, though some platforms are still a work in progress http://code.google.com/p/playn
It is super curious why Apple decided to allow apps to access the Address Book freely. I'm releasing an app on the App Store next week and I definitely thought about all the evil things I could do to my users because Apple provides them no protection. And as a developer looking for success on the App Store, it is very tempting.
I once considered the possibility of uploading the entire address book to my servers, too. In fact, I even considered email/sms spamming everyone in those address books with "invitations" from the address book owner to download my app. Of course, I did not end up doing any of that nefarious stuff. Not even uploading the address book for innocent "Add Friends" features. But the fact remains that given the freedom to do so, almost every developer will be, at least, tempted to take advantage of it. Most will.
I honestly don't think Path did anything wrong and I'm sure they kept the information secure on their servers. It's Apple that somehow let this one slip through.
I think you misunderstand. I think Path did nothing wrong not because they "weren't caught". I'm sure they keep their data secure and they only use it to benefit the user's experience - ergo, nothing wrong. On the other hand, if say, they spammed people's address books, then I would think they are in the wrong. Or if they sold the data, then they are in the wrong. But as far as I can tell, they did nothing bad.
Oh and by "let it slip through," I didn't mean the app itself, but the fact that the SDK requires no authorization from the user for any app to access the address book. Like the author of the article said, it requires it for location. Why on earth doesn't it require it for your contacts? They're arguably much more valuable.
Perhaps, to Apple, it's really not your data. When you put data on an Apple device, they consider it to belong to Apple. So the appropriate permission was granted when they accepted Path into the App Store. Maybe this is the Apple way of thinking?
As far as I know Stripe does not do ACH? We've actually been looking all over the place for an ACH processor with an API (aka a Stripe for ACH) and have had absolutely no luck. And the one company we found, for some reason, wouldn't take us on as a client (I guess we're considered high-risk). Anyway, I wholeheartedly agree with the need for an "Stripe for ACH". If you actually know of one please let me know.
Crediting. As far as I know PayPal Mass Payments requires the recipient to have a PayPal account (in fact, we do use Mass Payments for customers who choose to be paid by PayPal). Crediting via ACH, on the other hand, merely requires routing and bank account numbers - which is something everyone has! The whole point, which neither PayPal nor Dwolla solve, is to use the existing financial network, not create a new means of money exchange.
I'm interested in chatting in more detail with you about this. Would you drop me an email if you would like to discuss further? My contact details are in my profile.
There's actually a lot of "AirBnB for Activities." Our company used to be Skyara (http://www.skyara.com). We ended up pivoting to RAVN (http://ravn.com), which is more of a "Amazon for Activities," per se. I think we were definitely one of the first ones to try to enter the "AirBnB for Activities" space but had a very hard time.
While in theory it sounds like a great concept, the key to realize is that no "AirBnB for Activites" can ever be an "AirBnB for Activities." What I mean by that is: the part of the "AirBnB for X" business model that makes it work is the part where you have a very low marginal cost to renting out an existing resource that, presumably, is getting very low utilization. I.e. a car sitting in a garage, an empty couch. The marginal cost of renting those out... is basically zero. However, with Activities, the resource at play is actually time! A person needs to take two hours out of their day to offer a walking tour, cooking class, etc.
Arguably, time is the most scarce resource we have. People value their time highly, which means the marginal cost (in this case the opportunity cost) of them offering an activity is very high. Add to that the fact that individuals do not benefit from any sort of economy of scale, and that most likely means that they cannot compete with businesses on price (which is arguably where AirBnB is winning in its biggest market, NYC).
So of course, I'm not saying an "AirBnB for Activities" is not possible, but some fundamental problems make it significantly more difficult than one might initially expect. Personally I think Vayable is doing a great job, but time will tell...
Oh also, AirBnB took something that already was happening (sublets on Craigslist) and just rebranded/made it better. Not much "Activities" activity going on on Craigslist. It's mostly for services, like painting, plumbing, car mechanics, etc. So you sometimes question if the demand actually even exists?
Anyway, I could write a loooong post-mortem on Skyara but you get my point.
How are these sites overcoming the chicken and egg issue of attracting interesting activities from locals? Gathering enough visitors to the site to make transactions meaningful?
From building a marketplace at Ridejoy (YCS11), I can tell you that this early market building is very unique to each team/product/market and also one of the most valuable "secret sauces" for the company. Anyone who really knows probably won't tell you, and most people who might write a response are mostly guessing. At least that's what I think.
These marketplaces share a lot of core business similarities to that of the daily deal market as early as four year ago, no? At scale (depending upon which niche you choose for your site) will require money in to make "money out". No one in this thread seems to be highlighting this with the exception of those sites listed, little VC dollars have been invested thus far.
It's a serious question and one that's not secret sauce, I'd argue. The execution of your business and that of any sticky viral hooks you can build in will leave you at the winner's circle years from now.
