gavinjoyce

We're using GPT 4 to create personalised content for product demo videos for sales teams. Demo here: https://www.linkedin.com/feed/update/urn:li:activity:7049764...

Even though it's much slower, GPT 4 is way more consistent than 3.5. The OpenAI APIs have had lot of flakiness in the past couple of weeks, we retry requests up to 10 times to work around this

Hey HN. My co-founder and I begun working on Vidu 10 months ago. We are both ex-Intercom - he ran the outbound sales team at Intercom, I was an early engineer.

Vidu aims to help creative sales and marketing teams stand out in a prospect's inbox by allowing them to create hyper-personalized content in seconds. Our first iterations of our product focused on just-in-time use cases [1], it takes about 10 seconds to generate a GIF with our extension and pop it into an email. We're now working on adding integrations to unlock automated use cases, our first Zapier integration was released in beta this week.

On the tech side, we use Blender (for motion tracking and rendering [2]), Ffmpeg, Elixir/Phoenix and Ember.js and we host on AWS.

We decided early on to bootstrap and focus on building and selling. Happily, we recently reached profitability and we're hoping to soon reach a point where we can begin to expand our team.

Questions / feedback is very welcome, thanks.

[1] https://www.vidu.io/use-cases [2] https://www.vidu.io/learn/recording-great-gifs

Here's a graph showing ships / day from 2013 to 2015: https://youtu.be/NoCxHTxpmSQ?t=299

Sorry, I meant to say we ship to production about a hundred times per day, not hundreds of times per day. We've shipped continuously since the very early days of Intercom. [1]

We have a solid CI/CD pipeline meaning that every good merge to master hits production a small number of minutes later. Most of these changes are pretty small, focused and routine, adding a new button behind a feature flag, a db migration, a bug fix.

These small changes add up over time to a steady stream of highly polished features and improvements.

[1] https://www.intercom.com/blog/shipping-is-your-companys-hear...

The idiomatic way of shipping an ember app is with ember-cli-deploy [1] which, among other things, will ensure that it ships a production build.

[1] https://github.com/ember-cli-deploy/ember-cli-deploy

Perhaps you're measuring a development build?

I just tried a new ember 3.15 app production build, the JS payload comes in at 712.29 KB (180.80 KB gzipped)

`ember new myapp && cd myapp && ember build --environment='production' && ls -la dist/assets`

I think this is fresh opportunity for Ember to become mainstream again, modern Ember is so clean and productive

At Intercom, we've been incrementally upgrading our almost 6 year old Ember app to Octane as the features have landed over the past 8 months. Our app continues to be in great health and we continue to ship hundreds of times a day with a constant stream of features that our customers love [1]

Octane is a huge leap forward for Ember. Its APIs are extremely well designed, composable and cohesive. The new Glimmer components and @tracked properties have resulted in waves of negative diffs as we refactor parts of our app to Octane and, IMO, are an advancement in the state-of-the-art component state tracking / reactive UI.

If you've tried Ember before and were turned off by some of its slightly weird APIs (computed properties, component APIs like tagName, classNames & event handling, the ember object model), you should take a second look.

With Octane, Ember is a framework for rapidly building high quality web applications that will remaining healthy over time as the web platform and JS ecosystem rapidly changes.

[1]: https://www.intercom.com/changes/en

1.x to 2.0 was a little rough, but so much better than the "all apps left behind" approach of Angular 1.x to 2.0. Ember's 2.x to 3.0 upgrade path was much improved as earlier mistakes were learned from.

Trajectory matters, and Ember had got a really great trajectory for apps that value longevity now.

We started on ~v1.4. Ember has improved in every dimension since then. ember-cli, the ember inspector, contextual components, data down actions up, much better docs, an open RFC process, the ember addon ecosystem, the experimental glimmerjs, a smooth approach to deprecations and major version released. A lot of small steps and the odd big leap really adds up.

Performance is great now. The rendering engine has been rebuilt (without major changes to the templating syntax) and the new glimmer-vm architecture yielded huge performance and payload size wins and continues to deliver incremental performance gains every 6 weeks.

I've never considered error reporting an issue in the past, but I may just not remember the pain. It's not an issue for us now though.

If you (or anyone else reading) would ever like to chat in person, feel free to reach out:

https://twitter.com/gavinjoyce/status/928719024644612096

We've been using Ember at Intercom for over 4 years to build our main app. We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges. The 6 week release cycle is great.

We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.

We've been using Ember at Intercom for over 4 years to build our main app.

We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges.

We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.

Ember is not fading away for us, it's enabling us to focus on continuously shipping better and better features to our customers.

Here's a playlist of technical videos which explore the Glimmer VM internals:

https://www.youtube.com/playlist?list=PLpAr6J-75N24C-XQgIUDM...

We're running Ember 2.2 on Intercom and we've found it to be faster than 1.x. In addition to this, it looks like Glimmer 2 will bring significant render time improvement for both initial render and subsequent DOM updates.

It yields the same results in reverse order and also when the cache is primed for both and cleared for both

Many people have confirmed a major speed improvement. I've repeated this with an empty cache, primed cache and in different orders many times and have always got the same results. Having said that, a good number of people have reported seeing no speed improvement too.

Some further details on the issue: https://github.com/npm/npm/issues/11283

We began rebuilding Intercom with Ember.js in April this year. We now have 12 engineers working with Ember and both the pace of development and the quality of our output has been amazing. Ember bills itself as 'A Framework for creating ambitious applications' and we've found this to be very true. We upgrade to the latest point release every six weeks or so and this process has been painless.

Merchants could simply return the $ value of the product

> It seems that Ember Data is in a new round of development with alpha status

Ember Data isn't a requirement of Ember by any means. You can happily use these instead:

* jQuery.ajax

* https://github.com/ebryn/ember-model

* http://epf.io/

* https://github.com/zendesk/ember-resource

That's true, Ember doesn't have any data synchronisation mechanism over websockets like Meteor does. It is easy to update your data model from incoming messages but, as sambeau points out, pushing these data updates may not be a trivial matter.

There is nothing built-in but it would be straightforward to update your model data over web sockets. The magic of Ember bindings and observers will take care of the rest.

> I don't know if it's really worth the up-front cost of learning and slowing down initial development of a new product

This is true when considering the introduction of any new technology or when to pay down technical debt. The answer for you will likely depend on the complexity of the product that you are building, how important a great UX is, how close you are to shipping something, and whether the promise of building a clean and scalable browser application outweighs the short term benefits of delivering a "mess of ad-hoc jQuery and random objects".

I've worked within a medium sized team building a large Ember application and have seen first hand how beneficial it can be when dealing with application complexity and a need for precise UX attention to detail, even when using a much earlier version. I've also experienced frustration with the documentation and quickly moving goalposts as the framework evolved towards v1.0.

Happily, everything has become so much easier in the last few months. The documentation and guides are now a fantastic resource after a huge push from the team and community. The framework itself requires much less boilerplate code, Ember automatically generates controllers, routes and views at runtime should you not need to customise their behaviour. The addition of support for promises across the framework has resulted in more terse and consistent application code. I've found the community to be very helpful and I'm excited to see how it will grow over the coming months.

> So there will end up being a chunk of the app with Ember, and a (functionally separate) part of the app not using Ember at all.

I'm helping a client do exactly this at the moment. Their current application consists of a many pages with ball of JavaScript and jQuery sitting on top of their clean REST API. They want to raise the bar for what their application can do and the medium term goal is to deliver a single page Ember application. In the short term, we're building some of the most complex new features in Ember. These features will be accessed through modal iframes for a time allowing us to build out the Ember application without having to rebuild everything.

Thanks, that bug has been fixed

I purchased one of the first blocks, the Irish flag in the top left. It brought a steady stream of useless traffic, unsurprisingly.

Nice, thanks. I've been building an alternative to ActiveModel::Serializers which provides these features.

https://github.com/RestPack/restpack-serializer

In the light of your proposals, I'll either implement JSON API or switch back to AM:Serializers. Side-loading, paging and Ember Data compatibility are my main goals.

A few additions that I'd like to see:

* Standardized paging

* Optional side-loading - GET /albums.json?include=artists,songs

* Multiple meta elements - so we'd have "albums_meta", "artists_meta" and "songs_meta" in the example above. This allows us to include 'has_n' relationship paging data.

These are poor interview questions which reflect badly on the company. Interviews are a two way process.

Would you be happy publishing your keystrokes if your IP address was removed?

Probably another victim of ill-thought-out complex password requirements. If it's too complex to remember, it will probably end up on a post-it note.