The Web Design & Development Megathread

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

o.m. 94: Nov 23, 2009

So, I've had a toy idea for a Twitter account that I want to generate tweets and send them out on a (non-annoyingly) consistent basis, but I'm wrestling with the best way to do a high-level implementation.

I have a server sitting around I want to put to use, and my thought is to write something in PHP that will generate the tweet string, then make a POST request to the Twitter API. Presumably I'll need the PHP OAuth extension to integrate the account I need (as per v1.1 of the API) as well.

However, if I do it in PHP, I'll either have to make the request manually or set up a cron job. The other alternative is to write a Python script that would maintain an uptime and make the same RESTful requests as above.

Does this sound reasonable, or am I way off here?

# ¿ Jul 2, 2013 09:31

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 22:58

o.m. 94: Nov 23, 2009

YO MAMA HEAD posted:

My first PHP project was a cron'd bot that made OAuth tweets, but something broke a few weeks ago... it worked fine while it lasted, though. http://twitter.com/dogsmcgee

Was it the Twitter API change? It finally kicked in for a lot of our client's sites a week or so ago, and those who failed to heed our warnings last year were left with a bunch of empty site feeds.

# ¿ Jul 2, 2013 13:10

o.m. 94: Nov 23, 2009

Oh man where to begin. There are a billion solutions to your spec, although the requirement for mathematical computation means you need to get serious.

In the long run, I think it is worth doing the following:

* Get virtualization software like VirtualBox or VMWare
* Install a Linux distribution like Ubuntu Server (should meet your needs and has lots of support)
* Set up a stack. Apache to handle requests, MySQL for database and PHP for your code is a popular example but you could use Django, or Ruby and some other kind of database.
* gently caress around trying out some kind of CMS. Drupal is a powerful choice. It will handle, gracefully, 4 of the 5 requirements you have.
* Decide the CMS is too weird and restrictive and go for a proper big boy framework like, say Symfony.
* Find out a way to integrate your computation stuff with whatever framework/CMS you decide on. You'll want it to be server-side and fast as balls, running on your stack.
* ...
* Profit!

I'm being totally LAMP-centric in my suggestion, there are plenty of other ways to go about this but the most important thing is to take away is that you need a Linux box running a stack. This is what everyone does these days. You can then take your Linux set up, buy some decent hosting (I use Linode, the important thing is to use a provider who just gives you a server with total freedom) and put it live in the same fashion.

# ¿ Aug 16, 2013 12:55

o.m. 94: Nov 23, 2009

Boner Slam posted:

Yeah that's fine, it's always been like that. Set up a server, set up sql, do poo poo.

I heard somewhere PHP is no longer cool. Though that's why I am asking here, as I can not really confirm the validity of the things I pick up.

As far as the computation is concerned, I know that Python has some numerical packages. I would like to include R at some point probably as well. I read it can input C, so maybe there's a way to interface via that.

What is the difference between a framework like Django and a framework like Symfony? Is it just the same thing for different languages or is there a fundemental difference?

I don't think PHP was ever cool

It's popular, and has improved considerably over the past 10 years, especially if you employ a framework that uses it properly. I guess it's down to preference. The main point is that you should work with something that does all the boring stuff for you (handling users, security, routing etc) so you can focus on delivering your functionality and front-end. Set up a Linux stack, install various options, and get a feel for something. It's mostly preference.

# ¿ Aug 16, 2013 13:19

o.m. 94: Nov 23, 2009

Winter is Cuming posted:

Anyone have any recommendations for an intro to programming math book? My math aptitude is probably at a 10th grade level now that I've let it go to poo poo.

Rosen's "Discrete Mathematics and its Applications" is a very good book; lots and lots of progressively difficult exercises (as opposed to a handful of head-scratchers) which is the best way to drill this stuff into your brain. Most important topics are covered - logic, sets, functions, graphs, recursion, algorithms & complexity; even a little number theory and proofs.

o.m. 94 fucked around with this message at 15:32 on Oct 3, 2013

# ¿ Oct 3, 2013 15:28

o.m. 94: Nov 23, 2009

I don't think you should use <i> for anything since it doesn't have any real semantic value. My understanding that <b> and <i> are deprecated in favour of <strong> and <em>

# ¿ Feb 20, 2015 18:48

o.m. 94: Nov 23, 2009

Jimlit posted:

Its really up to preference if having it in an <I> helps you out then do it. I'd also go for the latter implementation since putting other stuff in the icon container seems like it would make both elements pretty inflexible.

This is just false, neither are depreciated and saying stuff like this just creates completely unnecessary confusion.

Sorry, I wasn't exactly sure if it had been officially deprecated. I just don't see the point in <i> or <b>, but I would love to hear where they can be used effectively, and aren't in there for legacy reasons. It also doesn't make any sense to use it for icons except that both start with an i, which in itself is somewhat misleading. A more generic container like <span> seems far more appropriate. I would like to know more reasoning behind this, though.

EDIT: Had a jolly good read, I see HTML5 has equipped <i> and <b> with semantic value. That's fine then. It seems using it for icons is still arbitrary however, but like you say it's nitpicking territory.

o.m. 94 fucked around with this message at 19:51 on Feb 20, 2015

# ¿ Feb 20, 2015 19:42

o.m. 94: Nov 23, 2009

There's better ways to do this, but your current solution is probably workable for now.

Each link calls toggleChapter(), right? So pass in a unique argument for each link: toggleChapter("01"), etc.

You can then use this string to decide which image to load.

# ¿ Mar 2, 2015 17:42

o.m. 94: Nov 23, 2009

caiman posted:

Can somebody who uses a _typography.scss partial explain to me the benefits of doing so? In my limited experience I've found it to be a pain, but maybe I'm not doing it right. To me it seems that _typography forces me to split up what should be single rule sets into two separate rule sets, thus complicating things. Say for instance I have a class of .button, which has both formatting styling rules (position, margin, etc.), and typographical styling rules (font-family, color, etc.). They're now spread across two different .scss files. Every time I need to make a change to .button, I first have to ask myself "Is this a formatting thing or a typography thing?" and I go to the appropriate file. More brain power, more work. Or am I totally misunderstanding something?

You're not wrong. The thing is, you have to treat structural approaches to CSS/SCSS like code styling. Everyone has a favorite approach, but the main thing is that everyone has to agree on one approach and stick to it. Consistency trumps additional the extra bit of cognitive load that some people may feel. For instance, I loathe this indentation style:

code:

for (foo) {
   bar();
} else {
  baz();
}

I seriously hate it. I hate the poo poo out of it. But if that's what's been agreed by the team, or that's how the code is structured, as long as it's consistent, I'll pull up me breeches and get on with it, even though when I look at it it appears to me a jungle of brackets and sloppiness. I find the same approach is needed with CSS - because that's where consistency becomes even more important.

# ¿ Mar 10, 2015 21:10

o.m. 94: Nov 23, 2009

Griffith86 posted:

Pretty much this, the pure designer role is a thing of the past thanks to rapid prototyping and the tools of today.

It's a lot easier (and generally quicker) nowadays to build beautiful complete interfaces without ever opening photoshop/illustrator/etc.

Sure if you're redesigning Mom's Church Choir website

# ¿ Mar 21, 2015 00:15

o.m. 94: Nov 23, 2009

Thermopyle posted:

The thing with recommending PHP for these simple requirements like templates a header and footer, and I've seen it happen a million times, is that the scope almost invariably increases. Particularly for beginners. Then you should have just used a better language to begin with.

And pray tell, what incredible technical scope, from a simple header and footer, will this beginner be faced with that PHP cannot address?

# ¿ Apr 8, 2015 09:23

o.m. 94: Nov 23, 2009

Maluco Marinero posted:

PHP can do includes. However if you want a static site generator there are far better tools such as Jekyll and the like. If you want a dynamic website you're better off using a framework. The only benefit you get out of PHP is you can run it everywhere, but after that, after you need to do actual programming in it, there are more than enough inconsistencies in the standard library and edge cases in how it works that you'll be getting held back by minutia when you're trying to learn how to program.

I must have misinterpreted the argument, I was assuming that when we say PHP, we mean PHP frameworks and libraries as included. I can't argue that rolling your own solutions in pure PHP is at all sensible for anything that faces the outside world - although of course it has great pedagogical merit.

# ¿ Apr 8, 2015 11:43

o.m. 94: Nov 23, 2009

I heard that in CSS1, you had to escape underscores which was awkward and not always well supported and I guess it just came from there, people preferred dashes out of convenience

code:

p.your\_mom

For instance

# ¿ Apr 16, 2015 12:30

o.m. 94: Nov 23, 2009

Is it acceptable to have the following, from an accessibility point of view (note this is just a demonstration, I am not concerned with HTML structure or element choice)

code:

<html lang="en">
  <head>...</head>
  <body>
      <h2 lang="fr">C'est un news headline</h2>
      <h2 lang="en">It's a news headline</h2>
  </body>
</html>

The point I'm trying to make is that on each page, the lang attribute is set appropriately (there's a language switcher between English and French), but there currently isn't any indication of change of language within the document (such as some content not having a translation so it defaults to English). The easiest way for me to do this is always to set the lang attribute, even if it matches the overrall page attribute. Is it OK to have this redundancy?

# ¿ May 6, 2015 14:50

o.m. 94: Nov 23, 2009

down with slavery posted:

You're going to want to handle your localization server-side

ugh i am you intolerable poo. That's not the question I asked

# ¿ May 7, 2015 08:59

o.m. 94: Nov 23, 2009

Leshy posted:

If this is the case, you apparently have some server-side logic that grabs the English content whenever a French translation is unavailable. It should not be too hard to modify that logic to add an appropriate lang attribute in cases where it does, which seems more efficient and a better way of doing things than always setting the lang attribute on everything.

Indeed; and on further thought I apologise to not coming to this conclusion earlier... I was being lazy and seeing if I could just paint every result with a lang attribute but the correct logic is pretty straightforward as you say, thanks!

# ¿ May 8, 2015 11:15

o.m. 94: Nov 23, 2009

I always thought that www was redundant because the protocol part of the address basically says what kind of resource you want, but having said that even using HTTP doesn't necessarily mean "give website" so I don't really know what to think anymore..... still looks bad though

# ¿ Aug 4, 2015 15:52

o.m. 94: Nov 23, 2009

fuf posted:

Can I get a lil insight on CSS selector efficiency? With SCSS nesting it's super tempting to not use any IDs or classes so the html stays really clean.

Like if I wanted to select:
code:
<header>
   <div>
      <a>Hello</a>
   </div>
</header>
I'd be inclined to use:
code:
header{
   div{
      a{
         color:blue;
      }
   }
}
But how much more inefficient is
code:
header div a {
compared to changing the html to
code:
<a class="link-color">
and just using:
code:
.link-color {
?

Is there some threshold beyond which nesting becomes prohibitively inefficient?

Selecting on elements is not really a good idea, because if the markup needs to change, so does the CSS. Whereas, selecting on classes seperates things and makes it reusable.

Second problem with your selecting of elements is that it's very specific - you want to try and select as generically as you can so that you have the ability to be more specific in the future, with minimal selectors. If you select deeply, you find yourself running into all kinds of trouble with !importants when you come to maintain it a year later. Classes again help solve this problem.

Thirdly, lots of nesting inside SCSS quickly makes things complicated and hard to parse, IMO. I use nesting sparingly, and take advantage of the better side of SCSS like variables and mixins. Things get even MORE out of control if you aren't using classes to target stuff.

# ¿ Sep 9, 2015 20:50

o.m. 94: Nov 23, 2009

Grump posted:

Welp. Just graduated and looking for a development job and realizing I have nowhere near as many skills as I should.

Think of it like when you learn to drive. You take a bunch of lessons and pass your test, but actually properly learning to drive takes the next couple of years out on the roads. A decent employer understands this and will support you; just be positive and work hard the rest will sort itself out.

# ¿ Jun 15, 2016 12:24

o.m. 94: Nov 23, 2009

Drupal 8 has actually been significantly rewritten and pretty much all of core does not resemble v7 any more. As someone who started on 6 and has done a lot of work on 7 I am very happy with the significant effort core maintainers have put into modernising and improving it. The entire hook system will be almost completely eradicated by 9.

Unfortunately it still remains a CMS that takes a few years of practice before you can start making maintainable, solid and consistent sites because there are several approaches to site building and modules sometimes make it hard to follow a particular paradigm. For instance, Commerce enforces you to implement Rules via the UI, even if you don't like to use Rules (I don't).

So while I agree 7 is pretty bad, the legacy code is being very aggressively removed now and having delivered a couple of sites with 8 I would call the developer experience vastly improved. There are new v8 modules such as YAMLform that make the previous contenders (Webform) look downright pathetic relative to how long they've been in development.

# ¿ Oct 28, 2016 17:25

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 22:58

o.m. 94: Nov 23, 2009

Ugh is multiple H1s ok semantically and accessibility wise now? Some of my clients pay this company loads of cash to identify failure to meet AA and they keep raising poo poo that's just plain wrong or a misinterpretation of the WCAG spec

# ¿ Nov 27, 2016 17:21

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