One thing to note why you'd always have all these ideas and others don't is because you're a founder and they are programmers. It takes a certain level of conviction to voice your ideas. Not every programmer has that conviction.
Looks do matter but they only get you so far. What's more important is how you carry the conversation. You can make up for pretty much everything if you are good with words.
This is a classic technique for influencing people. The rule of thumb is nobody likes to be criticized in any situation whatsoever. The worst thing you can do is to tell them they are wrong. One way to get a difficult message conveyed is to get the other person say "yes" a few times before being told things as they are.
id first last birth_year
1 Blaise Pascal 1623
2 Gottfried Leibniz 1646
3 Emmy Noether 1882
4 Muhammad al-Khwārizmī 780
5 Alan Turing 1912
6 Srinivasa Ramanujan 1887
7 Ada Lovelace 1815
8 Henri Poincaré 1854
(I know, I know. It is possible to configure MySQL encodings correctly. And given that they've put a lot of engineering thought into choosing MySQL, they certainly have.)
Don't know if it's still an issue, but I once setup mysql, with an id of binary(16) to store UUIDs, and used 0-padded conversions for legacy id's... when trying to port over existing records I discovered the index on a binary field was a "case-insensitive" textual index by default, so started getting conflicts when the ascii equivalent of "a" and "A" as a byte was inserted, etc. This was about 15 or so years ago, but the irksome nature still sticks with me to this day.
I wouldn't be surprised if that behavior remains the same. MySQL seems to be fine with long-standing bugs and other sub-optimal behavior hanging around, eg. https://bugs.mysql.com/bug.php?id=20786 .
I used both Postgres and MySQL and in my opinion encodings are more difficult to setup with Postgres. You need to change some "template" when creating a database to use unicode. Otherwise it will use latin1. I do not even understand what a database "template" is, how it is related to encodings, and why it is so overcomplicated.
In MySQL there is no templates and you can change the encoding of a table at any time using ALTER TABLE statement.
And in cloud IDEs like c9.io you cannot use unicode collations in Postgres because they need to be installed separately and they are not installed.
You certainly don't need to change any templates when creating a database, CREATE DATABASE and createdb both support specifying the encoding.
Changing encoding of a table (or a database after creation) is usually not a wise thing to do; since the db engine is not going to go over all the data and convert it anyway, so if your data is corrupted now it will remain corrupted. If one simply needs to tell the DB to treat the data differently without worrying about data conversion, the encoding of a database is stored in `pg_database` and can be changed with an UPDATE query.
And this is all from the official documentation. I'm not a Postgres expert.
I can confirm. I recently set up a private mattermost server. Because the host I'm running it on didn't have the UTF-8 locale on by default (I think), Postgres defaulted to Latin-1, and mattermost ran fine, right up until someone sent a UTf-8 character which is unrepresentable in Latin-1.
I believe some of the data aggregation is done by reverse engineering APIs of mobile banking apps. You can easily do that by setting up MITM proxy to intercept requests. In some cases, you may need to decompile app binaries to decipher password encryption algorithms.
I also think it's super important to make something you can sell in addition to making something people want. Frankly, there are so many things people want but not every founder has resources or is well-equipped to sell it.
Your goal as a founder is to maximize chances of __your__ success. Having the right founder-market fit goes a long way.
Definitely agree. It's easy to think of a cool "new social sharing blah" idea -- but guess what? If you're a new founder, without a large persuasive network to get word out to free users -- you're going to have a very hard time.
On the other hand, if you build something useful, and can start racking up subscriptions by doing some footwork (talking to users, giving out free accounts, etc), then you've got a much better chance.
I think this is part of the reason who RoR, MEAN and other such frameworks are so popular. They tend to be easier to setup and many developers love it. My own theory is there are so many bad devs out there so that contributes to the hype because so may devs end up adopting it.
MEAN isn't as easy to set up and I would not compare it to Rails at all. Rails is a backend framework—MEAN is just a bunch of technologies used together to have an API and a SPA. I'd actually argue, from personal experience, that newbies have a lot of trouble with MEAN because while there's a CLI tool MEAN doesn't have the community support, conventions, etc. that Rails does. Plus, you have to learn too many things at once.
