The combination of high and climbing price to earnings ratios for a smaller subset of tech firms, outsize retail investment in tech (cloaked by people buying crypto), and macro environment factors like high interest rates stimulating risky lending has me swapping this bubble toward the top of the list.
I propose that by prioritizing profits and productivity we were already globally dependent on tools to find meaning in the world before generative AI. This seems to be the society we already have.
In other words, I don't think MultiModel will be immune to fairly straightforward adversarial image attacks (although you might need a different adversarial network to generate them).
Furthermore, the problems being addressed by MultiModel (image recognition, natural language processing, machine translation) are problems that already have fairly robust deep learning results.
I'd be more interested if MultiModel showed significantly better results on problem areas that are currently difficult for standard deep learning approaches.
In addition to the Postgres knowledge, this post also provided me with tremendous help in building a sane data architecture for RESTful web services in Haskell.
Also what's notable is that it was opened up in 2009--a full five years before all the hubbub about core and corefx. And it's under Apache 2.0, so if any organization has any problems swallowing the terms of MS's patent grant on .NET Core, they have a more palatable option.
I second the Firebase recommendation. Facebook killed off their BaaS acquisition while Google doubled down on theirs. If you prefer open-source, Horizon (http://horizon.io/) is a great alternative to Firebase but does not have many of the key features like file storage and iOS/Android SDKs.
I completely agree that on its own, the querying functionality can be quite tedious for anything complex. I linked to this solution on the comment above as well: https://github.com/davideast/Querybase
> Querybase is in an experiment and not for production
Also since Firebase doesn't allow more than one filtering field with orderByChild(...) I'm guessing Querybase will do all the work on the client. This is less than ideal since the data has to be downloaded first.
Querybase is also making permutations of all the data you may wish to query. Needlessly taking up space on your server that will have to be retrieved. Wasted bandwidth etc.
I wouldn't call this an "issue" as much as a "limitation". Just as you can develop a data denormalization process for any use case, you can develop one for Firebase.
Here's a practical example of doing joins with Firebase (written by David East who is also the star of that video you linked): https://github.com/davideast/Querybase
As I found out today if you want the analytics data in CSV, or query it to any level that's useful beyond "We have 5 users in Stockholm on KitKat", you'll need the next service tier up, which is $25 per month per project.
But if you want basic analytics, then it's free & easy.
Horizon is a scary recommendation right now given the recent shuttering of RethinkDB (the company). It might still be a great choice, but I would give the community some time to coalesce and see where things end up before recommending it for new projects.
I really like Firebase, but for specialized cases as others mentioned. The realtime updates are solid, and the iOS SDK at least is deep enough to let you dig into edge cases when needed (like, how many clients are listening to this node?). But I use it like an in-memory store to sync live data. Can't imagine having to use it like a full database - I use Parse for storing more permanent data across tables.
Yes it's google behind ... but you should rewrite the whole application. That's why I respect Facebook about their decision to opensource the Parse Server. The is the beginning of the Open Backend world. With Parse Open Source everybody will get Personal MBaaS :)
See further: https://www.morningstar.com/news/marketwatch/20250123167/six...