The Web Design & Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›362 »

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

gmq posted:

I have been playing around with Meteor, which uses Mongo for its database layer. I'm not sure how to structure my data as I'm not sure where to denormalize, where to embed, etc.

I'm making a deck builder for a TCG with player card lists and a general library. Right now the main collection is 'Cards', with each document being a single and unique card. Then I have the Users collection which has the standard User documents. My problem is with the decks and the userCards collections.

Originally my Deck collection was like this:
JavaScript code:
[
  {
    // 'card-slug': amount of cards
    'card-slug': 1
    'card-slug-1': 3
    'card-slug-2': 1
  },
  {
    'card-slug': 4
    'card-slug-1': 2
    'card-slug-2': 1
  }
]
and then I joined with the card collection in the client layer. However, I have been reading that I should have been embedding the cards in the Decks, ending up like this:
JavaScript code:
[
  {
    'name': 'Name of the Card',
    'type': 'Type'
    'slug:':'card-slug',
    'deck-slug': 'test-deck-2',
    'deck-name': 'Test Name 2',
    'owner': 3
  },
  {
    'name': 'Name of the Card',
    'type': 'Type'
    'slug': 'card-slug',
    'deck-slug': 'test-deck',
    'deck-name': 'Test Name',
    'owner': 1
  },
  {
    'name': 'Name of the Card 2',
    'type': 'Type'
    'slug': 'card-slug-2',
    'deck-slug': 'test-deck',
    'deck-name': 'Test Name',
    'owner': 1
  },
  {
    'name': 'Name of the Card',
    'type': 'Type'
    'slug': 'card-slug',
    'deck-slug': 'test-deck',
    'deck-name': 'Test Name',
    'owner': 1
  }
]
The userCards collection is simillar, a list of cards and an amount, without the deck property.

What would be the best way to structure something like this? (besides "Don't use mongo")

Don't use mongo.

But if you really have to you have two options as I see it: you keep your related data in separate collections and join the way you would in a SQL store (although all done in the application layer), or you keep the data as embedded documents nested in a hierarchy.

Use the relational model for data that you want to access from either end (the parent and the child separately and at different times), and the embedded documents for data that you will only ever want in the context of it belonging to it's parent, otherwise if you want to do something like aggregate all of the child documents you will have to use a pain in the rear end aggregate query and transform a bunch of documents instead of just running a simple find query.

I would go with relational unless you're very sure that the data is not at all relational and you will only ever rant the embedded document in the context of its parent.

# ? Sep 17, 2015 21:32

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 02:51

an skeleton: Apr 23, 2012; scowls @ u

Skandranon posted:

Do you have a specific reason to do this, or does someone think MongoDB is magically faster?

It's because we are trying to move our team to the MEAN stack as a standard. The previous app, including the db structure was architected by someone who eventually got fired so the DB is a piece of crap anyway. If we have to rewrite some of the relational crap in the new app, fine, but I just want to evaluate whether that is a retardedly difficult task (it doesn't seem horrible but I've got <2 years experience under my belt).

Maluco Marinero posted:

Yeah, I would evaluate why when it comes to changing from SQL to NoSQL. The moment you change you lose the relational guarantees SQL can offer, and then your schema (there is always a schema, it's just either implicit in the code or explicit in the DB) is extremely dependant on the code maintaining those guarantees, so you'll be writing more than just transition code potentially.

I expect there to be some bumps in the road, but the DB isn't some insanely complex masterpiece, its just an order processing app. Most of the DB complexity in terms of foreign key constraints etc. would be housed in the following 2 implicit "requirements":

1) There is a "Group > User > Order" hierarchy where if any of the parents are deleted you would want to delete the children, etc.
2) There are products and product prices that can be different per "Group" but are also frozen in place once an Order reaches a certain status.

I'm pretty sure these aren't 100% correctly implemented in the current app, honestly, so its going to be work to fix them no matter what.

Bonus question!

We have 2 main "parent" documents. Let's call them 'groups' and 'products'. The groups house lots of things including users and orders (which are made up of products). If we are referencing orders and users individually a lot, should they be moved out from under 'groups' into their own 'parent' documents?

# ? Sep 17, 2015 21:42

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

an skeleton posted:

It's because we are trying to move our team to the MEAN stack as a standard. The previous app, including the db structure was architected by someone who eventually got fired so the DB is a piece of crap anyway. If we have to rewrite some of the relational crap in the new app, fine, but I just want to evaluate whether that is a retardedly difficult task (it doesn't seem horrible but I've got <2 years experience under my belt).

I expect there to be some bumps in the road, but the DB isn't some insanely complex masterpiece, its just an order processing app. Most of the DB complexity in terms of foreign key constraints etc. would be housed in the following 2 implicit "requirements":

1) There is a "Group > User > Order" hierarchy where if any of the parents are deleted you would want to delete the children, etc.
2) There are products and product prices that can be different per "Group" but are also frozen in place once an Order reaches a certain status.

I'm pretty sure these aren't 100% correctly implemented in the current app, honestly, so its going to be work to fix them no matter what.

Just do MEAPostgres instead, migrate the database to PSQL and use good design and everything and you'll be happier in the long term.

The MEAN stack is just kind of a dumb easy thing to say like LAMP anyway, there's nothing really that great about using Express.js with mongo anyway aside from a very slight bonus in sharing JS like objects.

Don't use mongo

# ? Sep 17, 2015 21:46

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

an skeleton posted:

It's because we are trying to move our team to the MEAN stack as a standard. The previous app, including the db structure was architected by someone who eventually got fired so the DB is a piece of crap anyway. If we have to rewrite some of the relational crap in the new app, fine, but I just want to evaluate whether that is a retardedly difficult task (it doesn't seem horrible but I've got <2 years experience under my belt).

The main problem you'll have with Mongo is that, instead of having the database doing things like join or filter operations, you'll have to do them in your application layer. Which can mean transmitting a LOT of data to retrieve just a single item. For some scenarios, Mongo makes sense, but by no means all. I'd focus on moving everything else in the stack and stick with whatever DB you have, or start over again in Postgre or a new MySQL

# ? Sep 17, 2015 21:49

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

an skeleton posted:

Bonus question!

We have 2 main "parent" documents. Let's call them 'groups' and 'products'. The groups house lots of things including users and orders (which are made up of products). If we are referencing orders and users individually a lot, should they be moved out from under 'groups' into their own 'parent' documents?

If your data has things related to one another, you should use a relational database unless there is really, really compelling reason to do otherwise. Don't use Mongo.

# ? Sep 18, 2015 06:44

an skeleton: Apr 23, 2012; scowls @ u

Lumpy posted:

If your data has things related to one another, you should use a relational database unless there is really, really compelling reason to do otherwise. Don't use Mongo.

Can we not "enforce" those relationships through parent/child relationships? If so, (and I don't see why not), that would encompass most of our relations.

# ? Sep 18, 2015 15:37

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

I'm sorry if this is off the current discussion, but how do you tackle performance (load time, size)?
I know there are tools to measure, but what am I measuring for? What is too slow? If I don't give an actual number, then others will want to add more and more features and umpteen marketing tags.
I was at a conference with other people from other companies recently and they all mentioned actually removing features/tracking to get the site to be faster, but gave no goal number.

# ? Sep 18, 2015 15:58

Space Kablooey: May 6, 2009

an skeleton posted:

Can we not "enforce" those relationships through parent/child relationships? If so, (and I don't see why not), that would encompass most of our relations.

Relating one thing to another is the one thing that relational databases excel at.

To answer your question, not in mongo. If you want to relate stuff but use mongo as you database, you'll have to do it on the application code.

Space Kablooey fucked around with this message at 16:22 on Sep 18, 2015

# ? Sep 18, 2015 16:20

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

The Merkinman posted:

I'm sorry if this is off the current discussion, but how do you tackle performance (load time, size)?
I know there are tools to measure, but what am I measuring for? What is too slow? If I don't give an actual number, then others will want to add more and more features and umpteen marketing tags.
I was at a conference with other people from other companies recently and they all mentioned actually removing features/tracking to get the site to be faster, but gave no goal number.

This is really a failure of the business analysis portion. They should have a specific goal for how fast an application should be for various things. For example, Google has a specific < 1s time limit for it's queries. A product doesn't get released until it is faster than 1s. Saying "Make X faster" without a benchmark of what is good enough is impossible to really satisfy.

# ? Sep 18, 2015 16:43

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

an skeleton posted:

Can we not "enforce" those relationships through parent/child relationships? If so, (and I don't see why not), that would encompass most of our relations.

Well, if your only relation is "Blah" objects that have child collection of "Gloop" objects, and every Gloop is a unique thing unto itself and only is a child to a single Blah ever, than Mongo will probably work well for you. If you have relations more complicated than that (a Gloop can be a child of more than one Blah, etc.) then you will be writing lots more code to handle things you get for free in a relational store.

You can make Mongo do just about anything: it's a question of how much extra code you have to write around that (and dealing with the bugs that come with writing code) and dealing with the fact that code now defines your relationships, and the headaches around that.

If you are going to go the Mongo route, check out https://github.com/gaearon/normalizr which is a way of structuring data in a way that makes it a bit more sane to deal with. Maybe.

# ? Sep 18, 2015 18:14

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Skandranon posted:

This is really a failure of the business analysis portion. They should have a specific goal for how fast an application should be for various things. For example, Google has a specific < 1s time limit for it's queries. A product doesn't get released until it is faster than 1s. Saying "Make X faster" without a benchmark of what is good enough is impossible to really satisfy.

That's my point. How do I figure out what good enough is? Since one hasn't been provided to me (through the failure of the business analysis) how do I make one of my own to then tell the business analysts?

# ? Sep 18, 2015 18:17

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

The Merkinman posted:

That's my point. How do I figure out what good enough is? Since one hasn't been provided to me (through the failure of the business analysis) how do I make one of my own to then tell the business analysts?

Point this at your site and it it's all green you did good? https://developers.google.com/speed/pagespeed/insights/

# ? Sep 18, 2015 18:33

bartkusa: Sep 25, 2005; Air, Fire, Earth, Hope

The Merkinman posted:

That's my point. How do I figure out what good enough is? Since one hasn't been provided to me (through the failure of the business analysis) how do I make one of my own to then tell the business analysts?

Do some math, dude. It's all just math.

Measure some basic stuff.
Make some bullshit correlations. (eg: users who use feature X buy Y% more poo poo)
If you can, translate visits or clicks or something into dollars.
Run some experiments.

Suppose you have a registration button on your website, but it's slow to load. Hopefully, you know how frequently that button is clicked, per X pageviews or per Y sessions. If you're lucky, you know the average lifetime $-value of a registered user.

Roll out a performance improvement to some people, and measure how much the registration rate changes. If you can't find a perf improvement, try making it slower for a handful of people, and measure the decrease.

If the slow registration button is preventing people from doing something else that's valuable, try cutting it for a few people and measuring how much other stuff goes up.

# ? Sep 18, 2015 18:58

Impotence: Nov 8, 2010; Lipstick Apathy

comedy option i've seen is also setting the entire body to invisible or off-screen, then hooking domcontentloaded and setting it visible all at once, possibly with a horrendous css3 upward-fadein transition so it appears to load faster even though it doesn't

# ? Sep 18, 2015 19:02

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Biowarfare posted:

comedy option i've seen is also setting the entire body to invisible or off-screen, then hooking domcontentloaded and setting it visible all at once, possibly with a horrendous css3 upward-fadein transition so it appears to load faster even though it doesn't

http://snapdrafts.com/ - doing it "right" lol

# ? Sep 18, 2015 19:17

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

The Merkinman posted:

That's my point. How do I figure out what good enough is? Since one hasn't been provided to me (through the failure of the business analysis) how do I make one of my own to then tell the business analysts?

Well, if you are the developer, and they give you vague requirements, pick the interpretation you like best. 0.01% faster IS faster. Conversely, you can send them some emails explaining how their requirements suck (need clarification). I don't know how contentious your relationship is with the people who do business analysis.

# ? Sep 18, 2015 19:28

kedo: Nov 27, 2007

Genuinely curious ��why are you folks opposed to loading screens for a website? Loading screens exist in practically every other type of application, what's wrong with using them on the web?

I'd posit that if your site is going to take more than a couple seconds to load, it'd be better to show one followed by a quick reveal rather than showing your chugging application. Besides the fact that snapdrafts has a ~2 second fade-in, it's not offensive to me in concept.

e: Should note that I'm all for doing your best to ensure your site loads quickly, but I'm talking about situations where a longer load time is unavoidable.

# ? Sep 18, 2015 21:01

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Because server-side data retrieval and rendering shouldn't be noticeably slow on production infrastructure. Sure, a widget on the page might need a loading spinner but the containing page ought to get there and show something as fast as the connection allows and that gap is the browser's problem.

# ? Sep 18, 2015 21:16

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

kedo posted:

Genuinely curious ��why are you folks opposed to loading screens for a website? Loading screens exist in practically every other type of application, what's wrong with using them on the web?

I'd posit that if your site is going to take more than a couple seconds to load, it'd be better to show one followed by a quick reveal rather than showing your chugging application. Besides the fact that snapdrafts has a ~2 second fade-in, it's not offensive to me in concept.

e: Should note that I'm all for doing your best to ensure your site loads quickly, but I'm talking about situations where a longer load time is unavoidable.

It's a UX thing... users will get frustrated if it takes longer than 2-3 seconds and are likely to leave your site for another one. So, it's better to get something shown as fast as possible, and break your loading into smaller chunks. People won't leave if just the calendar & twitter feed are loading, but the other content is visible, but will if the whole site looks unresponsive.

# ? Sep 18, 2015 21:22

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Skandranon posted:

Well, if you are the developer, and they give you vague requirements, pick the interpretation you like best. 0.01% faster IS faster. Conversely, you can send them some emails explaining how their requirements suck (need clarification). I don't know how contentious your relationship is with the people who do business analysis.

Oh I see the confusion now...
Performance isn't really on anyone's radar, and I'm trying to make it be the case. (in fact I've heard through the grapevine that one associate explicitly said performance didn't matter). So if I'm saying "our site should be faster", I don't want to be the one to vaguely say "faster" instead of something more specific.

Lumpy posted:

Point this at your site and it it's all green you did good? https://developers.google.com/speed/pagespeed/insights/

Thanks, this is measurable and I can point to the readout and say "see? we need to do X to make this stuff green"

The Merkinman fucked around with this message at 21:10 on Sep 19, 2015

# ? Sep 18, 2015 21:39

kedo: Nov 27, 2007

Oh I understand the concept behind showing something as quickly as possible. I'm just not sure that the reaction "loading screens are bad, always," (which, granted, I'm reading in between the lines and maybe straw-manning a little here) is true especially in situations where a longer than 2-3 second load time is unavoidable.

Hell, Gmail has a loading screen and it certainly takes longer than a second to load. Especially if you happen to be in a coffee shop on a lovely connection. Especially if you're checking your email on your computer that you've tethered to your phone. My point is that in situations like this where you literally cannot deliver something meaningful immediately, telling the users "seriously stuff is loading in the background," with a loading screen can be better than displaying only bits and pieces of a page.

I'd actually be curious to hear why Google chose to use one with Gmail. Total shot in the dark, but I'd imagine immediately showing pieces of the layout as they become available while showing a spinner while your email loads would feel strange and like you're looking at "just some website" rather than "my inbox." This would debatably result in a poorer user experience than only showing everything once it has completely finished loading.

\/\/ That's a valid distinction.

kedo fucked around with this message at 21:56 on Sep 18, 2015

# ? Sep 18, 2015 21:44

lunar detritus: May 6, 2009

kedo posted:

Oh I understand the concept behind showing something as quickly as possible. I'm just not sure that the reaction "loading screens are bad, always," (which, granted, I'm reading in between the lines and maybe straw-manning a little here) is true especially in situations where a longer than 2-3 second load time is unavoidable.

For me it's the difference between a webapp and a website. I don't mind if a webapp has a loading screen but a website should get me to the information as fast as possible.

# ? Sep 18, 2015 21:54

an skeleton: Apr 23, 2012; scowls @ u

Our app really isn't *that* complex. If we cant manage to get it to work decently in Mongo its probably more our fault than anything. Will report back crying when I've realized how right you guys were

# ? Sep 18, 2015 23:33

onemillionzombies: Apr 27, 2014

I'm very new to web design and I recently made a modern website for a small business I work for. Everything seems great except the new wholesale form which I put up for them is getting all of its confirmation emails sent directly to customer's spam folders. It's using the exact same from/sender addresses as the old wholesale form, but those confirmation e-mails are getting through just fine.

The new wholesale form is using PHPMailer, would trying SMTP perhaps get the job done?

# ? Sep 19, 2015 00:18

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

an skeleton posted:

Our app really isn't *that* complex. If we cant manage to get it to work decently in Mongo its probably more our fault than anything. Will report back crying when I've realized how right you guys were

If you're dead set on doing it Mongo, go nuts. It's probably a bad decision, but if you are just looking for some after the fact justifications, say it works great with Angular and Node because it serves up JSON well.

# ? Sep 19, 2015 02:25

Impotence: Nov 8, 2010; Lipstick Apathy

onemillionzombies posted:

I'm very new to web design and I recently made a modern website for a small business I work for. Everything seems great except the new wholesale form which I put up for them is getting all of its confirmation emails sent directly to customer's spam folders. It's using the exact same from/sender addresses as the old wholesale form, but those confirmation e-mails are getting through just fine.

The new wholesale form is using PHPMailer, would trying SMTP perhaps get the job done?

send via something like amazon ses instead.

# ? Sep 19, 2015 04:14

an skeleton: Apr 23, 2012; scowls @ u

Skandranon posted:

If you're dead set on doing it Mongo, go nuts. It's probably a bad decision, but if you are just looking for some after the fact justifications, say it works great with Angular and Node because it serves up JSON well.

I really want to get some experience working with it. Our manager is insistent on moving that direction, for me to argue for a relational database is going to be me going against the grain of literally everyone else, so yeah. We will see :unsmith:

# ? Sep 19, 2015 04:23

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

an skeleton posted:

I really want to get some experience working with it. Our manager is insistent on moving that direction, for me to argue for a relational database is going to be me going against the grain of literally everyone else, so yeah. We will see

In the meanwhile, maybe get then to read this as well, http://lucumr.pocoo.org/2012/12/29/sql-is-agile/ schemas are awesome.

Sorry about the broken link, fixed.

Maluco Marinero fucked around with this message at 20:34 on Sep 19, 2015

# ? Sep 19, 2015 04:59

neurotech: Apr 22, 2004; Deep in my dreams and I still hear her callin'
If you're alone, I'll come home.

Maluco Marinero posted:

In the meanwhile, maybe get then to read this as well, http://lucumr.pocoo.org/2012/12/29/sql-is-agile/, schemas are awesome.

Link's broken. It has a trailing comma

# ? Sep 19, 2015 16:14

BlackMK4: Aug 23, 2006; wat.; Megamarm

I'm new to web dev and work at an agency. I've ended up lead (read: only) dev on a small project (think 18 templates + blog) which was scoped out to use WordPress, which is the path I've gone down with no real guidance. Learning live. Templates in the form of page-templatename which are tied to Advanced Custom Forms + ACF Repeater plugin, then pages are created using the template dropdown and the fields filled in.

My question is - is this the normal route? Would I be better off moving to Drupal for future projects? I also looked into Bolt a little bit and liked what I saw a lot (minus the no repeater field thing). I'd also heard of people doing stuff like using Angular as a frontend to a WP API and kinda laughed, was I wrong to laugh?

We have some clients on Sitecore, one on Kentico, and a ton on WP. We generally use Turnkey AWS for prod/dev servers. Pretty much everything is flexible and I can work in whatever framework/language/etc/etc that I want. Just looking to see what better options are out there going forward.

# ? Sep 21, 2015 01:14

Hed: Mar 31, 2004; Fun Shoe

I can't seem to get my gulp file to build babel with the ES7 list comprehensions enabled.

I try changing line 57 from:

JavaScript code:

    bundler.transform(babelify)

JavaScript code:

    bundler.transform(babelify, { optional: ["es7.comprehensions"] )

but no dice. Do I need to pull out something specific from the babelify import statement above to match the syntax on the babel page?

# ? Sep 21, 2015 01:48

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

BlackMK4 posted:

work at an agency [...] small project [...] WordPress [...] Advanced Custom Forms + ACF Repeater plugin

is this the normal route? [...] Drupal for future projects? [...] Bolt [...] Angular as a frontend to a WP API

Annoyingly with agency work your day is run by $$$, there's very little time available for learning in my experience.
You have three goals you want to accomplish: Do it Cheap, do it fast, do it well. You (and clients) usually have to settle for two of these three, but your ideal goal is to have all three at once.

If you throw in learning a new Framework (Angular, Drupal, Bolt, etc) to the mix, you're going to blow out your timelines by:
1. Learning something new
2. Training others in the new thing, because you need redundancy
3. Deal with all the bugs you didn't realise you were writing

This isn't great for the client or yourselves, because it'll take longer and it'll be done less well, thus it'll be more expensive for both parties.
That said, we can't all instantly know what we're doing, plus companies need to diversify and look at new tech, or we'd all still be using quill and papyrus. My point is, don't learn something new just because you think it might help, you need to consider what the knock-on effect of adding a new technology is going to be.

Regarding the actual software, you have to ask yourself these two questions: Does it benefit me, does it benefit my client?

Wordpress is drat popular, and most people know their away around it, or can be guided with a minimal of training on how to use it, because it's gone through thousands of iterations and user review. This makes it a joy to use as a CMS for both client and service provider.
Would it be detrimental to your clients if they had to use a new type of CMS? Would it be a pain to train them? My immediate reaction is that yes, it would cause these problems, because using Wordpress has been fine so far.

While you're looking at other frameworks, is there a problem you're actually trying to solve, or is this purely research about other options? Is there a part of working with Wordpress that's causing you pain, something it fails to do? something that takes a long time? Do these other frameworks solve this problem? Do they lack features Wordpress already has? Is the trade-off worth the effort?

# ? Sep 21, 2015 02:28

BlackMK4: Aug 23, 2006; wat.; Megamarm

You make a lot of good points.

Existing clients would stay on the same CMS, I am mostly talking about new business since we have a lot of projects in sales right now.

We are an agency new to the agile process (don't get me started, there are so many pains about it now) and everything is kinda in flux - we are getting our processes down. Going forward I plan to set up the CMS, create blank template files, map the pages to the templates, pass this to UX/Design/Copy, and be handed back a static site - at which point I plan to integrate everything into the CMS (using ACF). I am new to this, everyone is new to this. I don't know if what I am envisioning is a terrible idea or what. Right now I am being handed a prototype by UX and getting everything looking right, then gutting the data out of the page and throwing it into forms.

I guess moving to a different framework/CMS isn't really out of pain but more from a 'I want to learn new poo poo' standpoint. I guess what I'm trying to convey is that I am really new and I've never really had someone around to tell me how things SHOULD be done - I was thrown to the wolves three months ago and am loving it. Am I going about CMS integration the right way? Am I using the right CMS? Am I using the right frameworks (jQuery / Foundation in a src directory and have uglification/SASS with Grunt)? etc.

BlackMK4 fucked around with this message at 03:04 on Sep 21, 2015

# ? Sep 21, 2015 02:57

v1nce: Sep 19, 2004; Plant your brassicas in may and cover them in mulch.

Lumpy posted:

If your data has things related to one another, you should use a relational database unless there is really, really compelling reason to do otherwise. Don't use Mongo.

This is a 90% correct answer, but people always gloss over what the real problem is: You can't do joins in MongoDB.

Relationships in Mongo are "possible", but they're provided at the driver (application) level, not the DB level (for instance, PHP's MongoDbRef class).
Importantly you need to know that relationships in Mongo are just pointers for other objects in the DB Collection. You have to explicitly fetch the related data in another query. Mongo's stupendous speed usually doesn't mean there's any real performance penalty to this when it comes to straight-up retrieval of data.

The real problem comes when you want to do a Join query to find-something-by-something-else. This simply isn't possible in Mongo, and it's what 90% of people want from their database system.
Mongo's compelling use cases are unstructured data storage, and aggregation. It does both of these things fantastically. And most people seem to forget that it's perfectly OK to run two databases at the same time - SQL and NoSQL can coexist. They're two different tools for two very different jobs.

The main architecture problem you'll run into is that it's easy to crowbar something like MySQL into doing things similar (but slower) to MongoDB, but it's drat near impossible to make MongoDB do some of the things SQL can do with ease. You will grow to hate both MongoDB and yourself if you choose to use MongoDB having only looked 2 feet in front of you, and not considered what you want to do with your data it in the long-term.

A great way to think about it - if you ignore Monog's aggregation system - is to imagine MySQL but where all your data is serialized to JSON and you can only fetch data by what's in that row (ID, or a field in the serialized data). You have to retrieve each object, check its structure, and then fetch anything it "relates" to by the ID, and repeat as deep as your desired data goes. Everything must happen at the application level.

an skeleton posted:

It's because we are trying to move our team to the MEAN stack as a standard.

Standardisation is a worthy goal, but you need to be mindful of using the right tool for the job. You wouldn't use a CSV to export/import a structured hierarchy, so make sure your standards allow people to use something other than a NoSQL DB if the application is going to require (or expand to require) queries that require on Joins.

an skeleton posted:

1) There is a "Group > User > Order" hierarchy where if any of the parents are deleted you would want to delete the children, etc.
2) There are products and product prices that can be different per "Group" but are also frozen in place once an Order reaches a certain status.

To be honest you could handle these scenarios with either system, and most of this would be handled by you at the application level, not the DB level.

an skeleton posted:

We have 2 main "parent" documents. Let's call them 'groups' and 'products'. The groups house lots of things including users and orders (which are made up of products).
If we are referencing orders and users individually a lot, should they be moved out from under 'groups' into their own 'parent' documents?

Now your data is starting to sound a lot more relational, and this is where Lumpy was correct to caution you about your choice of DB.
In Mongo, unless your Users are their own Collection (each a Document) you won't be able to reference them by a specific MongoID. This is going to be a problem if you're mapping your Orders to individual Users, or want to aggregate anything. Your current structure is exchanging features for ease of storage, which is totally not a good thing.
You could create a User Collection, and each User has a MongoID and Group MongoDbRef. Your Orders would then have a User MonogDbRef.

Congratulations, now you're using MongoDB as a relational database, because I'm assuming your Orders, Groups and Users all have a set structure.
What you're doing isn't actually that shocking at this point. You can even build reports based on this using the aggregation framework. You could probably figure out how much of a saving people are getting on their orders, and which group is getting the best deal and on which items, even with millions of documents worth of data.

However! This goes quickly south if, say, each user can have X number of profile fields, and each field is something like a list of "Location" or "Department", and people want to be able to change the names of those departments at will (but not the reference!), and then filter for orders by users who are in location "aust*". Now you have to do a Fields.find(name, "aust*") and get those results, then search for all users who possess those listed IDs, and then fetch all the orders for those users.

Congratulations, you've just performed a manual join in MonogDB. This is not a good thing, it's quite a lot of code, hard to paginate, heavy on memory, slow because walking the relationships happens application-side, and generally will not make you any friends.
You're thinking "well it's not that bad", but this is just the tip of the iceberg. Think about the last complex SQL query you had to write with more than three joins, and then see if you can figure out how you'd code that in Mongo. If you can't think of a query to do this with, you shouldn't be the person picking DB systems (same applies to whoever came up with your standard).

This kind of thing, unless firewalled behind a system that can make your life easier (like Doctrine, which will masquerade as SQL using DQL but still be slow about it) is something you want to avoid in Mongo. It gets worse as time goes on, and is absolutely not Mongo's strong-suit.
Remember that Mongo is primarily an unstructured data store and aggregation engine. If your data doesn't fit that criteria, you probably want to be using SQL, if only because it's easier to do Mongo-esq poo poo in SQL, but impossible to do SQL-poo poo in Mongo.

BlackMK4 posted:

'I want to learn new poo poo' [..] Am I going about CMS integration the right way? Am I using the right CMS? Am I using the right frameworks (jQuery / Foundation in a src directory and have uglification/SASS with Grunt)? etc.

It sounds like you're on the right path. At my last company our workflow was:
1. Everyone involved talks to client
2. Developer and designer do wireframes of design
3. Developer and designer spec up solution on paper, for client signoff
4. Designer transforms wireframes into actual designs, dev signs off, client signs off.
5. Designer cuts designs to HTML and CSS. Passes to Dev.
6. Dev integrates static designs with software.
Somewhere between steps 4 and 6 the Dev can also make anything that's unique to the site.

We generally used CakePHP for applications, and Wordpress for everything else. It was a pretty amicable relationship.

Using wordpress is fine. SASS, jQuery, Foundation are all fine. Maybe prefer Gulp over Grunt, but whatever works for you, though things like minification can be handled by WP Plugins rather than pre-compilers, depending on what your end goals are, how deployment works, etc.
Beware the new hotness, because it's always full of bugs and gotchas and bugger-all documentation. You'll also become the authority on it, which is a risky position to be in, and you'll have to train people.

What you've got is a good baseline by my eye. I'd say look at your workflow and see if you can identify any pain-points, like "I have to keep writing entity adapters when I fetch data from ACF. There's got to be a better way!", or "setting up wordpress takes forever!".
Learn the other stuff if you can sneak it in without much risk, or do it in your free time. I'd recommend resisting the urge to complicate your working life if at all possible, unless you can tell it'll be a great solution to a clients particular problem, and you can prototype something to prove your point.

Oh, also if you want to adopt a new technology within a company, it's a great idea to have two advocates doing the research; someone who loves the current stuff and can argue how you can solve the problem internally, or point out any downfalls with the new tech, and someone who wants to use the new stuff can argue how the new stuff will make everyone's life easier, and an arbitrator (a manager? lead coder?) can decide if it's worth doing it in production. This process was an agreed company strategy for everything, and "too hard' or "too risky' or "we don't want to do new things" were not options the arbiter could choose from; there had to be an affirmed outcome with solid reasons.

v1nce fucked around with this message at 04:05 on Sep 21, 2015

# ? Sep 21, 2015 03:59

McGlockenshire: Dec 16, 2005; GOLLOCKS!

For more "mongo doesn't do foreign keys and joins, so if your data gets joined don't use mongo" goodness, there's this classic article: "Why you should never use MongoDB."

Once you find yourself writing joins, do a huge favor to yourself and drop the article's URL in a comment in the source along with a brief apology for the next maintainer. They'll probably hate you a lot less for it.

# ? Sep 21, 2015 05:42

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

I have a weird situation that I need some help with. I've swapped the lovely, default checkbox input with font-awesome icons via the following CSS:

code:

input[type=checkbox] {
  /* hide the checkbox itself */
  display:none;
}

input[type=checkbox] + label {
  /* format the label text */
  font-size: 16px;
  font-weight: normal;
}

input[type=checkbox] + label:after {
  /* format the text proceeding the label */
  font-family: FontAwesome;
  display: inline-block;
  margin: 5px;
}
/* Set the icons that will be displayed according to the state of the checkbox input */
input[type=checkbox] + label:after { content: "\f096"; } /* unchecked icon */
input[type=checkbox]:checked + label:after { content: "\f14a"; } /* checked icon */

Unfortunately this prevents me from accessing the checkbox with the Tab key, as in the case of tabbing through the login form.

Before incorporating this method I do the following: type (username) > Tab > type (password) > Tab > Space (to Remember Me) > Tab > Space (to log in). However because the Remember Me input is now set to display: none the Tab order goes all out of whack and resets to the top of the page when I hit Tab after entering a password.

I tried setting a tabindex on the label but according to the HTML spec focus on a label gets passed on to the associated input. Since the input is hidden, I guess that means the tabindex gets reset, and the first element on the page ends up getting focus instead. Is there a cleaner way to handle this? The default checkbox is just too drat small for my taste.

# ? Sep 22, 2015 18:45

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Karthe posted:

The default checkbox is just too drat small for my taste.

You can adjust the size of checkboxes and radio buttons easily, at least on desktop browsers. Try:

code:

input[type=checkbox] {
    height: 2em;
    width: 2em;
}

# ? Sep 22, 2015 19:07

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

McGlockenshire posted:

You can adjust the size of checkboxes and radio buttons easily, at least on desktop browsers. Try:
code:
input[type=checkbox] {
    height: 2em;
    width: 2em;
}

Well I'll be damned, that was simple. I don't even need the the CSS I posted anymore. Thank you very much.

# ? Sep 22, 2015 19:24

onemillionzombies: Apr 27, 2014

So I've installed jotform on my website for our wholesale form to get around the issue of the confirmation email being sent to customer's spam folder. Jotform specifically requests that I use noreply@jotform.com, which uses Amazon ses as the mailer to avoid the spam issues. So for example an email from our form will be viewed as From: Customer <noreply@jotform.com>, reply-to: customer's e-mail, mailed-by: bounce.jotform.com, signed-by: jotform.com.

A web dev who I think is confused about what I've used seems to think that soon the confirmation emails will be marked as spam again, while jotform is adamant that it will always work. I'm completely confused how to appropriately get emails through without spam issues using PHPmailer. Any thoughts?

Update: and now customers aren't getting the auto respond e-mail after submitting. Does anyone have any reliable forms they know of that I can try out / buy? I simply don't have time to build one and need it working.

onemillionzombies fucked around with this message at 13:55 on Sep 23, 2015

# ? Sep 23, 2015 01:18

Adbot: ADBOT LOVES YOU

# ? Jun 4, 2024 02:51

kedo: Nov 27, 2007

We talked about this a few pages ago, but use Mandrill for transactional emails. PHPmailer is not fun to work with. For forms I like Gravity Forms, but that requires WP. Not sure what you're using.

# ? Sep 23, 2015 16:05

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Web Design & Development Megathread

«‹›362 »