xmatos's comments

AMP is not about fast websites, better user experience for either users or publishers, nor a trusted platform.

It's about google hosting your site and capturing data from it. It's a shitty idea and i can't understand why people use it.

Yes, make your website fast, please. There're plenty of guidelines and tests for that, but you don't need amp for that.

this was beautiful:

Every step in a software project is solving problems. You don't know how long it will take to solve the problem. You don't know how many new problems you might run into along the way.

I like the idea of a tool like this, but I'm not sure it's a better process than having migration scripts. And I dislike migration scripts.

To me, the perfect process would be, using an MVC web framework as an example, to generate a temp schema from models and run a schema diff tool like this, to update the destination database. That would eliminate migration scripts, but would probably slow down the db sync process, once your db start getting bigger.

Now, if you're not using an ORM, I think it's a bad idea to use a tool like this to update a production db from development. It will work for a single dev, but not for a team project, since you'd need a common dev schema that would be used as a source for the diff, and that will get clogged quickly.

It's still a nice tool to find and update small inconsistencies between different environments. Nice work!

Like it or not, that enforces the beauty of GPL. I'm positively sure, if it wasn't it, linux wouldn't be in its position today. I actually prefer the LGPL, as it doesnt spread through, or "contaminate", the rest of your code base.

I've asked myself that many times before and I'd say it's because it's not an easy task and often you need to get things done to meet deadlines, instead of developing a general solution, that although could save time in the future, might not help much in the short run.

Having said that, Django admin is the best example of that. I'm a huge fan of it and tend to use it on every project that fits a crud workflow, mainly business apps.

To give an idea of how much work goes into building something like that, it took 5 devs an year to build its first version, not to mention add new features and improve it.

Regarding the last point, yes, that's what I'm saying. And it's not a matter of opinion, but of decades of computer engineering best practices.

Your app's UX will depend on how much code runs on the client. It can vary from a dumb terminal, like classic web applications, where everything runs on the server, to smart or rich clients, where some code do run on the client, but is always related to the UI. In a client-server application, your app's logic should always run on the server.

I've worked on desktop client-server apps where the application logic was on the client and the server was mainly the database. It works, but you might end with clients with different versions trying to access the DB and you don't want that.

That's what server validation means. You should never trust clients. You shouldn't build a web app, which is a client-server app, entirely on the client. It's like reverse best practices. It will bite you.

Regarding having something else than sql, how much effort would be necessary to build a graphql server library that abstracts whatever you have on the server? Would you build something and release it to your clients with that level of maturity? And for what?

Why use GraphQL? Why not simply expose one endpoint that takes a sql data parameter, queries the db and return the result set as json?

Yes, you'd have to setup db security to allow those db commands to run only selects and restrict which tables are allowed to be queried.

How can using a new json query language, without any server libraries targetting relational databases be better than that?

How much work would be envolved to implement this on the server side and for what, exactly? to allow frontend devs to query without exposing separate endpoints?

Client-server applications should not run business code on the client. The only code that should run on the client is the UI's.

Sorry, this is simply wrong.

Hype and lack of critical thinking abolutely had their role, but mostly because it's so much easier than a relational db.

Relational db's are hard. You have schemas and query planners and the truth is, you have to take care of every single query. Every query counts.

The same query can take 30 seconds, or 30 milliseconds to run, depending on it using an index or not. You think it's ok for it to take 2 or 3 seconds, until it hits production and halts the server.

Mongo doesn't have any of that. Just load and dump json back and forth, which is perfect for fast prototyping.

Who cares about data integrity or technical debt?

GitLab's CI runs on every branch push, which I dislike, since you can push a branch that isn't ready yet for backup purposes. Although, it can be configured to automatically deploy only to staging, while having production deployment manually triggered. It can also run only on specific branches, like staging and master.

I was after a way to integrate deployment with task status updates, so once we updated a task status to Staging, for example, it would trigger a job to merge that task's feature branch to staging and deploy it. Once it gets tested and approved, we would update the task status to Approved, which would trigger a master merge and a push to production. To me, this would be the perfect solution.

Unfortunately, that's not how it works. It might be achievable through GitLab's web hooks and api, but i don't think it has a way to add a custom field to a task to store the related git branches and it only has an open / close status. We could use labels instead and parse the task description to extract the branch info.

What I've done in the past and worked great is use git hooks for deployment. That would handle deployment's heavy lift, but I'd still like to automate branch merging, by linking it to task status.

Has anyone done that? Is it a good idea? Are there any caveats?

Any tips or ideas would be highly appeciated. Thanks!

I love it!

I owned an Atrix with a lapdock, which was the first device to embrace this concept. Unfortunately, it was poorly handled by Motorola in the sense that you had to hack it to enable a full linux desktop, instead of what was basically a Chromebook.

What really made me give up on it was the fact that it never got updated, so you were stuck with Android 2. It was pretty useful even as a workstation and saved me as I used it exclusively for a couple of weeks, while my laptop needed repair.

I was already thinking about trying something like that again, by getting a phone that had hdmi output and i'll definetely take a shot on that! good luck to them!

Build tests against your app`s public interface. On a web app, that would be your controllers or API.

That will give you good coverage, while avoiding too simple to be useful unit tests.

It's really hard to foresee all possible input variations and business logic validations, but that doesn't mean your test suite is useless.

It just means it will grow everytime you find a new bug and you are guaranteed that one won't happen again...

I've said it before here, but the best web app I've built was basically Django, with bare minimum js to handle in-page effects.

I've been working on a project which is being ported to React for no reason, just because it's shiny, and it's been worst than expected.

Bundling the entire website into a huge js file doesn't make any sense. In practice, every time you make the slightest change, like adding a div, or changing a class name, your users have to re-download the entire thing.

Webpack takes 1GB of memory and 90 seconds to build it. Firefox Dev Tools eats all my ram if I try to reload the page with it open. And Redux is just bad. So much boilerplate for a dynamic language, with constants and if clauses to decide which action to dispatch. Apparently, it's ok to have presentation logic in a component, but god forbid internal state!

I do believe the reason front-end devs praise it so much is because it allows them to work solely in js, despite the end product being slow and heavy.

I always compare reddit's mobile site, written in react, with Hacker News. The first takes around 7 seconds to load on my cel phone, while the latter loads instantly.

No one but frontend devs care about js. The web hasn't become js centric and I bet it never will. It has become mobile first and all you need for 90% of that is css.

I don't know why fb and google spend money building these frameworks, but maybe because of this:

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

"But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP.

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t..."

Replace Microsoft with Google or Facebook...

I've been a web developer for 15 years now. Building the UI is always hard and where the waste of time is felt the most. That's why i prefer to work on the backend as much as i can.

I'm against the front x back end split. I think any web dev need to know html, css and js. That's mandatory. Besides that, you should definetely learn the server side too, specially databases, since they'are by far the biggest bottleneck and performance hog you'll need to optimize.

But I'm getting old and I know that because I think everything new is stupid. Once upon a time, we had RAD tools to build UI's, but unfortunately, that's lost in the past...

Amen! React might be the best tool for building hybrid mobile or even cross platform electron apps, but the truth is, it suck balls for web development​.

Bundling the entire website inside a single js file, that needs to be re-downloaded everytime you add a div or change a single css class is stupid, sorry.

Your website doesn't need to be pure text. It can be beautiful, modern and responsive. And it doesn't need much js for that.

The world has become mobile first, not js-centric. Pushing spa everywhere is just wrong.

...but the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features.

Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don't have to spend all their cycles catching up and reimplementing and fixing bugs...

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Cool Company Inc. People get worried about shiny.js and decide to rewrite their whole architecture for shiny.js because they think they have to. They are shooting at you, and it's just cover fire so that they can move forward and you can't...

The point of having it in a repository is not managing it through apt, but updating it without having to manually download deb files...

Am I the only one who misses an apt repository?

promising. it even has a clock widget :-)

https://www.youtube.com/watch?v=EtuDS0ntaJY

Best web app I've developed was basically Django, with bare minimum JavaScript to handle some in-page effects. People been trying to shoehorn desktop concepts in the web since forever and it will never work. A desktop app is installable, a web site is not. It makes no sense to wait your js app to download for the sake of smooth page transitions.

Take a look at reddit's new mobile site, written in react. It takes around 7 seconds to load, to display text and links. Compare that to HN's, which loads in 0.1 sec, for basically the same content.

SPA's have their place, for things like games or the likes of google maps. But for the rest, please respect the web paradigm . Your site will be simpler to build, faster and most importantly, lighter. The web world has become mobile-first, not js-centric...

really? and how's that? to my understanding, data integrity is not a feature on any of them.

but I asked that because I've been using redis a lot lately. I built a real-time analytics using bitmaps and I could use sorted sets to store time series data.

I really wanted to know what benefits do they offer to justify adding something else to the stack...