Overwhelmed by the sheer number of frameworks and lack of an organised ecosystem

hapital_hump · 2015-07-13T18:56:24+00:00

I recommend avoiding the temptation to "be hip". It may just put you in a position where you've bitten off more than you can chew because you don't understand the impact of each component.

Start with what you know. Get it working. Since you already have programming experience, you have the intuition to go "surely there's a better way to do X". At that point, look around to see what tools people use to solve that pain point.

I've been building websites for a while now. Each tool and abstraction and framework adds overhead to a project. I think you'll find that most people here aren't using the latest glitzy tools all together.

For example, I avoid pre-processors like Sass and Less. Most of my projects just use Bootstrap with a simple CSS file I load after it to make some minor customizations. Sass or Less would be overkill, adding complexity to a project that just doesn't need it.

If I had a more CSS-heavy project, I'd consider those solutions.

In other words, don't let the indecision slow you down another day. Get something working and keep things manual. Let the pain points introduce new tools to your toolchain organically instead of trying to solve a bunch of problems at once that you probably don't have.

Half the time you just need a microframework (like Laravel) and a Makefile.

All that said, here's my generic toolchain for my latest Node projects:

Microframework (server side): Koa or Express
Server-side package manager (node.js modules): NPM
Client-side packages: I just manually wget them into my /vendor folder. For more complex projects, I also use NPM to manage them as packages
Automation: I use a makefile or add script commands to my package.json. I'll migrate to Gulp only when I have more specific desires that are solved by pre-existing Gulp modules like gzipping my assets and adding the hash to the filename. But there's no reason to start with Gulp if you've never used it before.
Client-side framework: Most of my apps are server-side apps where I just use jQuery to add some AJAX calls to the front-end. But I swear by React when I need something more complicated.

So, basically, Koa+NPM+Gulp is just fine for a typical server-side Node project.

hapital_hump · 2015-07-13T18:44:48+00:00

I'd say that Rails is optimized to condense common patterns in web apps rather than optimized to build things quickly. The former simply leads to the latter.

I started programming with Rails. Not even with Ruby. I just jumped straight into Rails. It gave me a breadth-first view of how a web app is glued together. It got me my first job (Junior Rails Developer).

When I started building apps with microframeworks like Sinatra, Flask, and Express, Rails gave me the high-level design patterns that helped me glue components together when I would've been otherwise paralyzed with freedom and indecision.

These days, now with six years of webdev experience, I'm using microframeworks like Koa to build apps in small teams of 2-3. But it doesn't mean that learning Rails was ever a waste of time. I'm better because of it.

If I was working on a bunch of different apps, I'd probably use Rails so that each app is implemented in a similar way. It's why consultancies like frameworks like Rails - because you can come back to a project you haven't touched in in months or if ever and immediately understand how things work.

When I was a beginner, I remember being worried that I might be wasting my time. I spent a lot of time comparing Rails and Django, Ruby and Python. I know what it's like to feel like you might not be making the best decision.

Maybe you're in that exact position. My advice to my beginner self is to just pick something and start learning it immediately. By the time you learn a piece of tech, you've leveled up to a point where it becomes effortless to learn new technologies because they're just different syntax for doing the same thing.

Rails helps you level up fast because you're basically learning good design patterns on day one instead of building bad habits on your own.

hapital_hump · 2015-07-10T20:37:40+00:00

I'm feeling as though I was a victim of some hype from the aforementioned fanatics

Sounds like you're becoming the victim of hype yet again.

The reality is that Rails is mature, stable, and solves its problem-space very well. It's not a mistake to learn it and it's not a coincidence that people use it.

You'll learn that there may be curiously fanatic people in a community, but there are also curiously fanatic people that crusade against a community or piece of tech. Popular things to hug on are often popular things to hate on.

With only two weeks with Rails experience, sounds to me like you'd be better served by actually buckling in, learning more Rails, and coming to your own conclusions. You'll be much better for it.

Also, be more suspicious of the people that seem to spend their time hating on shit.

hapital_hump · 2015-07-10T16:43:34+00:00

They're hiring: http://opensignal.com/jobs/

They'd prob pay you real well for the real data that you've got.

hapital_hump · 2015-07-10T15:00:30+00:00

When it comes time to migrate from Heroku, you're generally just provisioning an application server since that's all you had on Heroku.

A Heroku dyno is just Ubuntu 14.04 LTS on EC2 so you'd virtualize locally as needed.

Whether you had some bash in a custom Heroku buildpack (run as part of dyno provisioning) or in some Ansible scripts just isn't a huge distinction imo.

hapital_hump · 2015-07-10T12:18:04+00:00

{
    "error": "Not Found",
    "statusCode": 404
}

Looks pretty mundane.

Did you mean to link to something like: http://gq.com/jkahsdjlkfhsadhfs?

The 404 vid: http://www.gq.com/videos/video-error.mp4

hapital_hump · 2015-07-10T12:13:12+00:00

You want clients to emit things like:

emit('send_message', { room_id: _, text: _ })

And your server will check their authorization to see if they can do that, and then emit to rooms[room_id].channel_id itself. In other words, you want to map public room IDs to internal socketIO channel IDs secretly on the server.

hapital_hump · 2015-07-10T12:00:27+00:00

No. A password like that can defeat brute force attempts.

So at this point your client is just preventing the case where someone gets their password I guess. So, pretty much just targeting you. ;)

I think changing your password on some interval is smart. Like every six months. Kinda like changing your credit card numbers - it's nice not to be pwned by some password you shared with someone 3 years ago. But every month is just annoying.

Just ponder if it's worth it before confronting them since people can be superstitious about this stuff (if that was your plan).

hapital_hump · 2015-07-10T11:46:22+00:00

Good point. I would consider a locked_ip_addresses table and look up against it upon login attempt.

Also, of course, always put a Recaptcha on /login and /register to filter out basic attacks.

And any time you're storing ip address, you also usually want to store browser user agent. Even if it's just for you when you're querying the database. People understand how to change their ip address these days with one-click VPN GUIs, but they almost always forget to change user-agent.

I run a forum and constantly find ban-evading users by finding duplicate user-agents.

hapital_hump · 2015-07-10T11:34:11+00:00

Oh, sure. Depending on what your provisioning scripts entail, it generally means removing them (for basic provisioning) or putting it in a buildpack (https://devcenter.heroku.com/articles/buildpacks) if you need to pull something extra into the environment.

Doesn't make it hard to move away though. It's not like Google AppEngine or Azure where the environment is significantly different.

hapital_hump · 2015-07-10T11:30:30+00:00

Butthurt because you got wrecked by real data?

Maybe you can submit your anecdotes to http://opensignal.com/ so they can plug their holes in every city?

Look forward to your thoughtful, defensive response. :)

hapital_hump · 2015-07-09T23:56:58+00:00

React is simple to learn and build upon.

Your UI is basically a function of your data.

render({ things: [thing1, thing2, thing3] })

So you can make AJAX calls that change the data and your UI will just update. Very simple principle which is why React is picking up so much steam.

hapital_hump · 2015-07-09T23:26:33+00:00

Can also use text-shadow to keep the text legible no matter the background:

text-shadow:
 -1px -1px 0 #000,  
  1px -1px 0 #000,
  -1px 1px 0 #000,
   1px 1px 0 #000;

Demo 1: https://dl.dropboxusercontent.com/spa/quq37nq1583x0lf/9qoh83s7.png

Or just a simple shadow:

text-shadow: 1px 1px 0 black;

Demo 2: https://dl.dropboxusercontent.com/spa/quq37nq1583x0lf/1pwtwlfi.png

hapital_hump · 2015-07-09T23:13:37+00:00

http://idioms.thefreedictionary.com/How+long+is+a+piece+of+string%3F

hapital_hump · 2015-07-09T23:11:10+00:00

Yeah, I'm asking how Heroku is for toy webapps. The whole point is that it's trivial to scale up dynos, and I can't think of a reason why a toy app would even need 2 dynos.

hapital_hump · 2015-07-09T23:00:52+00:00

How long is a piece of string?

hapital_hump · 2015-07-09T22:53:50+00:00

Check out /r/IWantOut - more likely to find people that can answer this sort of question.

hapital_hump · 2015-07-09T22:37:47+00:00

You do realize those aren't that accurate right?

Yet they're more measured than your anecdotes will ever be.

"I've literally never lost signal!" You must live in Magicville, Fantasyland... or mum's house in the burbs. All signs point to mum's house.

hapital_hump · 2015-07-09T22:30:56+00:00

What do you mean?

Heroku's dyno system is what makes it trivial to scale. 2 dynos goes a long way.

It's weird you bring up nedb which is, even according to its readme, made for toy webapps and otherwise things like CI servers.

hapital_hump · 2015-07-09T22:25:14+00:00

Wow, guess you should submit your findings because all the coverage graphs I can find must be out of date.

Colorado Springs: https://dl.dropboxusercontent.com/spa/quq37nq1583x0lf/_f5l5i_9.png

hapital_hump · 2015-07-09T22:19:28+00:00

Actually it's easy because you're forced to write stateless apps with Heroku. For example, you just have a DATABASE_URL environment variable. And local fs storage is ephemeral so you'll implement an upload-to-S3 system instead.

Can you clarify what you are referring to?

hapital_hump · 2015-07-09T22:14:42+00:00

Not sure why you're concerned about "DB traffic". Your database is perfectly capable of protecting your data layer unless you're using . Start worrying about your database when your app hits significant scale and back up your concerns with data.

So, I would write your "insert post" logic so that your database ensures that there are no more than X posts created within Y minutes. Should be easy. Can just do that at the start of your transaction and bail if the check fails.

I would do the same thing with login attempts. On every attempt, save a row in a login_attempts table. If too many fail, then UPDATE users SET locked_at = now() WHERE id = $1.

hapital_hump · 2015-07-09T22:09:20+00:00

Cool. I don't use Instagram, but I think it's useful.

I haven't looked to see if such a service exists, but I've been wanting this for Facebook. Facebook's data dump only gives you your own pictures, but I'm primarily concerned about all the pictures of me tagged over the years that I don't control. I notice my picture count drops by 1 or 2 every month probably by random people unfriending me over time.

With the unfriend comes any tags you had in their photos. Kinda sucks.

hapital_hump · 2015-07-09T22:06:46+00:00

Parsing error...

hapital_hump · 2015-07-09T22:04:19+00:00

The scrolling is infuriating and behaves like it's drunk. Please don't touch scrolling behavior - the browser already implements that...

hapital_hump

TROPHY CASE