#i probably should learn more about code html and script at some point

[simplyghosting]

“No one needs a computer anymore.”

Wrong.

>right-click

>inspect element

>delete annoying script housing this opinion

[queenlua]

hey, i started following you recently and ur bio says ur a hacker? any tips on where to start? hacking seems like a v cool/fun way to learn more abt coding and cybersecurity/infrastructure and i'd like to explore it but there's so much on the internet and like, i'm not trying to get into anything illegal. thanks!

huh, an interesting question, ty!

i can give more tailored advice if you hit me up on chat with more specifics on your background/interests.

given what you've written here, though, i'll just assume you don't have any immediate professional aspirations (e.g. you just want to learn some things, and you aren't necessarily trying to get A Cyber Security Job TM within the next three months or w/e), and that you don't know much about any specific programming/computering domain yet.

(stuff under cut because long)

first i'd probably just try to pick some interesting problem that you think you can solve with tech. this doesn't need to be a "hacking" project at first; i was just messing around with computers for ages before i did anything involving security/exploitation.

if you don't already know how to program, you should ideally pick a problem you can solve via programming. for instance: i learned a lot back in the 2000s, when play-by-post forum RPGs were in vogue.  see, i'd already been messing around, building my own personal sites, first just with HTML & CSS, and later on with Javascript and PHP.   and i knew the forum software everyone used (InvisionPowerBoard) was written in PHP.  so when one of the admins at my RPG complained that they'd like the ability to set multiple profile pictures, i was like, "hey i'm good at programming, want me to create a mod to do that," and then i just... did. so then they asked me to program more features, and i got all the sexy nerd cred for being Forum Mod Queen, and it was a good time, i learned a lot.

(i also got to be the person who was frantically IMed at 2am because wtf the forum is down and there's an inscrutable error, what do??? basically sysadmining! also, much less sexy! still, i learned a lot!)

the key thing is that it's gotta be a problem that's interesting to you: as much as i love making dorky sites in PHP, half the fun was seeing other people using my stuff, and i think the era of forum-based RPGs has passed. but maybe you can apply some programming talents to something that you are interested in—maybe you want to make a silly Chrome extension to make people laugh, a la Cloud to Butt, or maybe you'd like to make a program that converts pixel art into cross-stitching patterns, maybe you want to just make a cool adventure game on those annoying graphing calculators they make you use in class, or make a script for some online game you play, or make something silly with Arduino (i once made a trash can that rolled toward me when i clapped my hands; it was fun, and way easier than you'd think!), whatever.

i know a lot of hacker-types who got their start doing ROM hacking for video games—replacing the character art or animations or whatever in old NES games. that's probably more relevant than the PHP websites, at least, and is probably a solid place to get started; in my experience those communities tend to be reasonably friendly to questions. pick a small thing you want to do & ask how to do it.

also, a somewhat unconventional path, but—once i knew how to program a bit of Python, i started doing goofy junk, like, "hey can i implemented NamedTuple from scratch,” which tends to lead to Python metaprogramming, which leads to surprising shit like "oh, stack frames are literally just Python objects and you can manually edit them in the interpreter to do deliberately horrendous/silly things, my god this language allows too much reflection and i'm having too much fun"... since Python is a lot of folks' first language these days, i thought i'd point that out, since i think this is a pretty accessible start to thinking about How Programs Actually Work under the hood. allison kaptur has some specific recommendations on how to poke around, if you wanna go that route.

it's reasonably likely you'll end up doing something "hackery" in the natural course of just working on stuff. for instance, while i was working on the IPB forum software mods, i became distressed to learn that everyone was using an INSECURE version of the software! no one was patching their shit!! i yelled at the admins about it, and they were like "well we haven't been hacked yet so it's not a problem," so i uh, decided to demonstrate a proof of concept? i downloaded some sketchy perl script, kicked it until it worked, logged in as the admins, and shitposted a bit before i logged out, y'know, to prove my point.

(they responded by banning me for two weeks, and did not patch their software. which, y'know, rip to them; they got hacked by an unrelated Turkish group two months later, and those dudes just straight-up deleted the whole website. i was a merciful god by comparison!)

anyway, even though downloading a perl script and just pointing it at a website isn't really "hacking" (it's the literal definition of script kiddie, heh)—the point is i was just experimenting a lot and trying a lot of stuff, which meant i was getting comfortable with thinking of software as not just some immutable relic, but something you can touch and prod in unexpected ways.

this dovetails into the next thing, which is like, just learn a lot of stuff. a boring conventional computer science degree will teach you a lot (provided you take it seriously and actually try to learn shit); alternatively, just taking the same classes as a boring conventional computer science degree, via edX or whatever free online thingy, will also teach you a lot. ("contributing to open source" also teaches you a lot but... hngh... is a whole can of worms; send a follow-up ask if you want that rant.)

here's where i should note that "hacking" is an impossibly broad category: the kind of person who knows how to fuck with website authentication tokens is very different than someone who writes a fuzzer, who is often quite different than someone who looks at the bug a fuzzer produces and actually writes a program that can exploit that bug... so what you focus on depends on what you're interested in. i imagine classes with names like "compilers," "operating systems," and "networking" will teach you a lot. but, like, idk, all knowledge is god-breathed and good for teaching. hell, i hear some universities these days have actual computer security classes? that's probably a good thing to look at, just to get a sense of what's out there, if you already know how to program.

also be comfortable with not knowing everything, but also, learn as you go. the bulk of my security knowledge came when i got kinda airdropped into a work team that basically hired me entirely on "potential" (lmao), and uh, prior to joining i only had the faintest idea what a hypervisor was? or the whole protection ring concept? or ioctls or sandboxing or threat models or, fuck, anything? i mostly just pestered people with like 800 questions and slowly built up a knowledge base, and remember being surprised & delighted when i went to a security conference a year later and could follow most of the talks, and when i wound up at a bar with a guy on the xbox security team and we compared our security models a bunch, and so on.  there wasn't a magic moment when i "got it", i was just like, "okay huh this dude says he found a ring-0 exploit... what does that mean... okay i think i got that... why is that a big deal though... better ask somebody.." (also: reading an occasional dead tree book is a good idea. i owe my firstborn to Robert Love's Linux Kernel Development, as outdated as it is, and also O'Reilly's kookaburra book gave me a great overview of web programming back in the day, etc.  you can learn a lot by just clicking around random blogs, but you’ll often end up with a lot of random little facts and no good mental scaffolding for holding it together; often, a decent book will give you that scaffolding.)

(also, it's pretty useful if you can find a knowledgable someone to pepper with random questions as you go. finding someone who will actively mentor you is tricky, but most working computery folks are happy to tell you things like "what you're doing is actually impossible, here's why," or "here's a tutorial someone told me was good for learning how to write a linux kernel module," or "here's my vague understanding of this concept you know nothing about," or "here's how you automate something to click on a link on a webpage," which tends to be handier than just google on its own.)

if you're reading this and you're like "ok cool but where's the part where i'm handed a computer and i gotta break in while going all hacker typer”—that's not the bulk of the work, alas! like, for sure, we do have fun pranking each other by trying dumb ways of stealing each other's passwords or whatever (once i stuck a keylogger in a dude's keyboard, fun times). but a lot of my security jobs have involved stuff like, "stare at this disassembly a long fuckin' time to figure out how the program pointer got all fucked up," or, "write a fuzzer that feeds a lot of randomized input to some C++ program, watch the program crash because C++ is a horrible language for writing software, go fix all the bugs," or "think Really Hard TM about all the settings and doohickeys this OS/GPU/whatever has, think about all the awful things someone could do with it, threat model and sandbox accordingly." occasionally i have done cool proof-of-concept hacks but honestly writing exploits can kinda be tedious, lol, so like, i'm only doing that if it's the only way i can get people to believe that Yes This Is Actually A Problem, Fix Your Code

"lua that's cool and all but i wanted, like, actual links and recommendations and stuff" okay, fair. here's some ideas:

microcorruption: very fun embedded security CTF; teaches you everything you need to know as you're doing it.

cryptopals crypto challenges: very fun little programming exercises that teach you a lot of fundamental cryptography concepts as you're going along! you can do these even as a bit of a n00b; i did them in Python for the lulz

the binary bomb lab is hilariously copied by, like, so many CS programs, lol, but for good reason. it's accessible and fun and is the first time most people get to feel like a real hacker! (requires you know a bit of C beforehand)

ctftime is a good way to see when new CTFs ("capture the flag"s; security-focused competitions) are coming up. or, sometimes CTFs post their source code, so you can continue trying them after the CTF is over. i liked Stripe's CTFs when they were going, because they focused on "web stuff", and "web stuff" was all i really knew at the time. if you're more interested in staring at disassembly, there's CTFs focused on that sort of thing too.

azeria has good ARM assembly & exploitation tutorials

also, like, lots of good talks out there; just watching defcon/cansecwest/etc talks until something piques your interest is very fun. i'd die on a battlefield for any of Christopher Domas's talks, but he assumes a lot of specific x86/OS knowledge, lol, so maybe don’t start with that. oh, Julia Evans's blog is honestly probably pretty good for just learning a lot of stuff and really beginner-friendly?

oh and wrt legality... idk, i haven't addressed it here since it hasn't come up in my own work much, tbh. if you're just getting started you're kind of unlikely to Break The Law without, y'know, realizing maybe you're doing something a bit gray-area? and you can cross that bridge when you come to it? Real Hacking TM is way more of a pain-in-the-ass than doing CTFs and such, and you'll learn way more with the latter, so who cares lol just do the fun thing

[allalrightagain]

I promise I didn’t forget about you @lunapwrites, it just took me a bit to put my thoughts into (a lot of) words.

You said: I am... Extremely interested in this. Especially because my personal HC for Arithmancy and Runes is literally like Wizard Coding. Here for it.

I do agree that Arithmancy and Runes are like wizard coding, because I do think they share a lot of hallmarks of what we traditionally thing of code looking and acting like: you input a combination of symbols/numbers/letters into a text based system and get an output of whatever the code is supposed to do (ie magic, formatting your website, running an application, etc).

I should clarify that in my original post, I was thinking more scripting languages like Python, since that's what I’m currently studying, and it's specifically scripting languages that I was thinking resemble spells in canon (versus other types of code like markup languages (html) or compiled languages (C)).

I think of Arithmancy and Runes as closer to a compiled language— the finished product is a set of instructions /compiled/ into an application that works with the data it's given. In other words, you build the whole thing, then it can run the steps you built. Potions, in some ways, also fits into this category.

Scripting languages, otoh, aren't compiled, and are (at least, as I'm using here*) interpreted /scripts/ or individual pieces of code where specific actions are associated with each piece. It's faster and easier to use, and can, in many cases, be used piecemeal.

The linguistic methodology of spells in Harry Potter (specifically what we see of Defense, Transfiguration, and Charms) functions similarly to the syntax in scripting languages. One command performs an action, often but not always on a subject/input.

So you can use a command like print() where the text you want the application to spit out is in parentheses, and likewise you can shoot sparks, where you choose the color of sparks either mentally or verbally with a variant of the same command and directed wherever you point your wand.

Likewise, the commands are highly specific— for magic, the wrong wand movement or pronunciation can have disastrous results or be a completely different spell; for code, the wrong word or missing punctuation can cause a crash or a different action than intended.

Everyone I know who uses scripting languages regularly

1) has scripts they know off the top of their head,

2) has a file somewhere with the scripts they use just often enough that they forget in between uses, and

3) still has to google specific code or situations because they don't remember or don’t know exactly what their looking for.

So what I was struck with (as I looked up a highly specific command in a specific module which I've never needed before and will likely never need again) is that magic users would need to know a whole library worth of highly specific spells, and would probably still run into situations where they know there's a spell, but it's not one they've used before or regularly, and would have to look up and then apply that spell.

I would imagine that Hogwarts, not unlike a lot of IT/data science programs, start you off with a collection of easy and necessary scripts/spells, and teach a lot more theory than is initially obvious. It feels like you’re learning highly specific commands, which you are, but the goal of magical education is not unlike “learn to code” classes— to teach you the commands you’ll use so frequently you’ll never forget them, the rhythm and methodology of using those commands, and what to do when you don’t know the command.

Take switching spells for example— how often do you need to swap the positions of two similar sized objects? Probably not often, but you might use other, possibly more complicated spells that have two fixed objects, and it will use the same fundamentals and application, you’ll just have to look the spell up when you need it.

A final note on the application of this knowledge is that jobs that require coding knowledge typically involve a portion of the interview in which you prove your ability to fix or write code, sometimes in a specific language, and sometimes in whatever your preferred language is, so long as it's capable of performing the required tasks. However, once you get the job, they might have specific scripts that everyone uses within that team/company's specific function (in my last job, someone literally emailed me a 5 page long list that they'd been adding to since they started working there).

So it's reasonable to assume many wizarding world jobs both require a sort of “magical interview” where the interviewee is asked to perform specific spells or solve specific problems, and then once they get the job, are told the commonly used spells in that job. A person with good reasoning skills or a large working knowledge of spells would have an advantage over one who didn’t, but a person who already knows the specialized spells would have an even greater advantage in the interview process, but not necessarily after that.

(As a side note, code == magic adds a bonus layer to Snape's character specifically. We know he creates his own spells/code with the primary goal of hurting others, creepily pines for a girl who “friendzoned” him and hasn’t talked to him since they were fifteen, joined a terrorist org, and complained that other magical people don't use logic enough. Tell me he doesn’t hang out on the worst parts of magical Reddit/4chan/etc.)

*the actual languages that fit into scripting vs compiled aren’t necessarily cut and dry, and there are several that are used for both categories, where the individual scripts are compiled into a full application and used as such. Similarly, I think some transfiguration and charms could be used more like a compiled language— think of Hermione's bag with the undetectable extension charm, or Sirius and James' mirrors.

[iampikachuhearmeroar]

tl;dr political rant post:

it had been my goal from 12 years old to do an arts degree in philosophy (yes what a nerd- thanks to my dad playing a Great Courses philosophy dvd one morning in 2007 and my dad always taking me to the botanic gardens/the uni some weekends).

i graduated from my arts degree in 2018, with a major in english and a minor in philosophy. i was so, so lucky to even get into my communications & media degree (at first i was originally going to do marketing communications, advertising & PR)... but i realised that i was not made for business subjects- despite my mark101 tutor telling me she thought i had knack for marketing- something under this policy that i wouldn’t undertake due to the price hike for commerce/business degrees. nor was i made for a media degree. so i changed to arts & humanities.

although under this atrocious policy, english subjects are made “cheaper”- why on fucking should the rest of someone’s arts/humanities degree be so much more expensive, all depending on the fields they choose???? so you’re telling me, if i was instead to enter undergrad this year to do my english degree... that my english major would be subsidised, but my philosophy minor would be at double the cost (along with the few first year business and communications&media subjects i did), unless i forced myself to pick maths or science subjects that i would most definitely fail, no matter how much work i’d put into them??? or there’s languages- but much like maths/science- there’s the problem with my handwriting that stopped me trying french and even japanese (ironically, since it’s know for its ~painstakingly neat and orderly~ script- but my handwriting is still messy, disorderly and confusing asf).

*please note that most of this next section is just me being highly spurious and cynical. it’d probably work out fine*

but you’re also telling me that under this policy that i’d also probably have to forego my reasonable adjustments in those subjects (yes i still have trouble with my handwriting to this day) mostly because a lot of software still won’t let you write out maths problems properly or i’d have to spend twice as long trying to get a graph to work in excel or idek matlab (please teach me maths nerds)???? and most maths working out is probably better handwritten or whatever??? and that’s besides the point that i still can’t use excel at all 😂.

so with these classes then, would i be battling from day one of first year with professors to let me use a computer during exam periods (unless of course they use online/take home exam methods like philosophy)???? probably (im being very suspicious here because i don’t know how science/maths etc faculties work).

although i did get this once with one particular english professor; who used the excuse that he didn’t know how to set a computer up for exams because he had been on “sabatical for 4 years” or whatever and so “didn’t know the policies anymore”.... so then according to him it was apparently “the students job to do it.... especially since you’re in third year, miss williams”..... however, i was promptly then told by EVERY uni offical that i approached for help to do it for me.... and my other professors across my course that had done it for me, that it was in fact the PROFESSORS job/responsibility to set it up, and not the student’s??? like. help your students fuckwit professor grant??? honestly. anyway. aside from my personal struggles in the english department: let’s proceed. (this was a real incident btw).

would i be at a significant disadvantage to other students by not being able to use a computer during maths exams or science exams because of the drawing of diagrams and graphs and “showing your working”???? hell yes. would i want the professors in that department to probably condescendingly telling me all the time to “present my work neater and more precisely”? FUCK NO. it’s exactly why i avoided every maths and science subject in undergrad- even including the astronomy subject that i wanted to do- because it also meant that fellow students had to read my handwriting for practicals etc as well, that i wasn’t entirely keen on either. but i did not need the harsh reminders of “be more precise and infallible in your work presentation” that i’d had at school constantly for 11 years of maths lessons; affecting my mental health and performance in a subject during a uni semester.

moreover, that’s besides the fact that i’d flat out fail the “year 12 band 4 maths” requirements- unless they want to waive those- for first year maths/science subjects (at least basing it on my local uni).... considering that i actually skipped out on maths completely in year 12 by doing a TVET/tafe/technical college course in live theatre, production and events (which no surprises here, actually included maths anyway 😅).

because, fuck. is ANYONE seeing a trend in my study choices here? hell, i almost did a commerce/business dual degree with a tafe diploma in event management for crying out fucking loud. and you’re telling me that’s also doubled in price?? it’s obvious that i was interested in the arts & humanities and business subjects from the get-go. but under this policy- i’d be charged double for having my interest in event management, instead of say, biology (which is a subject that if it weren’t for mark scaling in my final hsc exam- i would have failed completely)??? utterly ridiculous.

i even contemplated doing a double degree with law at one point (or doing a legal studies major/minor- which is now a course at my local uni, but was not while i was there). however, law course fees have also doubled under this new policy. leaving that out of reach for me, despite that a double degree with law was out of reach for me anyway..... since my mark average was 65% and not at least 75% lol. but as if those marks averages will actually matter under this new policy.

under this bullshit policy, i’d be forced to take science/maths or even teaching (another field i had to avoid, since people can’t read my writing on a whiteboard from a distance half the time either.... besides the fact that i’m not really the ~teacher type~) subjects- all so that my degree price overall will be ”reduced”..... meaning that i would have to trade out my philosophy minor for something in maths/teaching/science (or maybe creative arts- since those fees stayed the same roughly)... instead of sticking to what i was good at: philosophy and other humanities/social science fields like sociology and history????

i understand that many people will snub me with saying “oh why did you even BOTHER going to uni if you were THAT indecisive about what you wanted to do?” which is something i’ve seen many older people saying on posts about this policy. but hell, i was 19 FUCKING YEARS OLD WHEN I STARTED UNI, FOR GODS SAKE. OF COURSE I WAS GOING TO BE FUCKING INDECISIVE ABOUT MY DIRECTION IN LIFE! because, newsflash fuckwits: not everyone has a defined career goal at 19. hell, i still don’t have one at almost 25..... since i’ll admit here, that i flunked out of my postgrad library course.... because i realised that i simply couldn’t cope with learning simple HTML, CSS and javascript coding for website design & user experience design 😂 (again help me computer wiz friends). yes, believe it or not, librarians have to know that today. and most people think that it’s just all about books (okay that was me, but i was wrong). also, if you’re wondering: postgrad library courses aren’t affected, thank god. but my point is, aren’t we meant to fuck up and pick the wrong things in life sometimes??? aren’t we meant to be indecisive about our choices in our late teens up until our mid 20s???

but now you’re telling students that their very first year of uni is practically set out for them, even for arts/humanities degrees (im not counting properly prescribed degrees such as engineering/science/communications & media (they had prescribed majors and prescribed first year subjects, which is why i left it. because i felt trapped in the prescribed marketing et al major etc); all because the government is telling them that “oh to make your first year cheaper: (A.) get good marks.... so that we don’t cancel your HECS place and (B.) pick subjects outside of the arts/humanities like science/maths/tech related subjects so that you don’t pay a whopping $14,500 for your first year of uni and will be more likely to be “job ready”. whatever the actual fuck “job ready” really means. and this all as if there ISN’T enough pressure for a 18/19 year old to succeed in their first year of uni already.

although, the one thing i’ll say is that my one year advanced diploma in marketing that i did in 2014, was $16,500. i still haven’t made any moves to pay it off. but it was constantly in the back of my mind during uni, both undergrad and postgrad. it was there as a reminder to pick cheaper subjects, so as to not greatly increase my combined hecs debt and vet-fee help debt; which is now sitting at $42,500. which under this new policy is the new price of ONE arts & humanities undergrad degree. i’d hate to be going into uni next year at 19 years old (or any age really) with that price tag on my degree.

anyway. that’s the end of my non-sensical rant. morrison and the rest of the libs etc can go fuck themselves.

[shinelikethunder]

Fandom Userscript Cookbook: Five Projects to Get Your Feet Wet

Target audience: This post is dedicated, with love, to all novice, aspiring, occasional, or thwarted coders in fandom. If you did a code bootcamp once and don’t know where to start applying your new skillz, this is for you. If you're pretty good with HTML and CSS but the W3Schools Javascript tutorials have you feeling out of your depth, this is for you. If you can do neat things in Python but don’t know a good entry point for web programming, this is for you. Seasoned programmers looking for small, fun, low-investment hobby projects with useful end results are also welcome to raid this post for ideas.

You will need:

The Tampermonkey browser extension to run and edit userscripts

A handful of example userscripts from greasyfork.org. Just pick a few that look nifty and install them. AO3 Savior is a solid starting point for fandom tinkering.

Your browser dev tools. Hit F12 or right click > Inspect Element to find the stuff on the page you want to tweak and experiment with it. Move over to the Console tab once you’ve got code to test out and debug.

Javascript references and tutorials. W3Schools has loads of both. Mozilla’s JS documentation is top-notch, and I often just keep their reference lists of built-in String and Array functions open in tabs as I code. StackOverflow is useful for questions, but don’t assume the code snippets you find there are always reliable or copypastable.

That’s it. No development environment. No installing node.js or Ruby or Java or two different versions of Python. No build tools, no dependency management, no fucking Docker containers. No command line, even. Just a browser extension, the browser’s built-in dev tools, and reference material. Let’s go.

You might also want:

jQuery and its documentation. If you’re wrestling with a mess of generic spans and divs and sparse, unhelpful use of classes, jQuery selectors are your best bet for finding the element you want before you snap and go on a murderous rampage. jQuery also happens to be the most ubiquitous JS library out there, the essential Swiss army knife for working with Javascript’s... quirks, so experience with it is useful. It gets a bad rap because trying to build a whole house with a Swiss army knife is a fool’s errand, but it’s excellent for the stuff we're about to do.

Git or other source control, if you’ve already got it set up. By all means share your work on Github. Greasy Fork can publish a userscript from a Github repo. It can also publish a userscript from an uploaded text file or some code you pasted into the upload form, so don’t stress about it if you’re using a more informal process.

A text editor. Yes, seriously, this is optional. It’s a question of whether you’d rather code everything right there in Tampermonkey’s live editor, or keep a separate copy to paste into Tampermonkey’s live editor for testing. Are you feeling lucky, punk?

Project #1: Hack on an existing userscript

Install some nifty-looking scripts for websites you visit regularly. Use them. Ponder small additions that would make them even niftier. Take a look at their code in the Tampermonkey editor. (Dashboard > click on the script name.) Try to figure out what each bit is doing.

Then change something, hit save, and refresh the page.

Break it. Make it select the wrong element on the page to modify. Make it blow up with a huge pile of console errors. Add a console.log("I’m a teapot"); in the middle of a loop so it prints fifty times. Savor your power to make the background wizardry of the internet do incredibly dumb shit.

Then try a small improvement. It will probably break again. That's why you've got the live editor and the console, baby--poke it, prod it, and make it log everything it's doing until you've made it work.

Suggested bells and whistles to make the already-excellent AO3 Savior script even fancier:

Enable wildcards on a field that currently requires an exact match. Surely there’s at least one song lyric or Richard Siken quote you never want to see in any part of a fic title ever again, right?

Add some text to the placeholder message. Give it a pretty background color. Change the amount of space it takes up on the page.

Blacklist any work with more than 10 fandoms listed. Then add a line to the AO3 Savior Config script to make the number customizable.

Add a global blacklist of terms that will get a work hidden no matter what field they're in.

Add a list of blacklisted tag combinations. Like "I'm okay with some coffee shop AUs, but the ones that are also tagged as fluff don't interest me, please hide them." Or "Character A/Character B is cute but I don't want to read PWP about them."

Anything else you think of!

Project #2: Good Artists Borrow, Great Artists Fork (DIY blacklisting)

Looking at existing scripts as a model for the boilerplate you'll need, create a script that runs on a site you use regularly that doesn't already have a blacklisting/filtering feature. If you can't think of one, Dreamwidth comments make a good guinea pig. (There's a blacklist script for them out there, but reinventing wheels for fun is how you learn, right? ...right?) Create a simple blacklisting script of your own for that site.

Start small for the site-specific HTML wrangling. Take an array of blacklisted keywords and log any chunk of post/comment text that contains one of them.

Then try to make the post/comment it belongs to disappear.

Then add a placeholder.

Then get fancy with whitelists and matching metadata like usernames/titles/tags as well.

Crib from existing blacklist scripts like AO3 Savior as shamelessly as you feel the need to. If you publish the resulting userscript for others to install (which you should, if it fills an unmet need!), please comment up any substantial chunks of copypasted or closely-reproduced code with credit/a link to the original. If your script basically is the original with some key changes, like our extra-fancy AO3 Savior above, see if there’s a public Git repo you can fork.

Project #3: Make the dread Tumblr beast do a thing

Create a small script that runs on the Tumblr dashboard. Make it find all the posts on the page and log their IDs. Then log whether they're originals or reblogs. Then add a fancy border to the originals. Then add a different fancy border to your own posts. All of this data should be right there in the post HTML, so no need to derive it by looking for "x reblogged y" or source links or whatever--just make liberal use of Inspect Element and the post's data- attributes.

Extra credit: Explore the wildly variable messes that Tumblr's API spews out, and try to recreate XKit's timestamps feature with jQuery AJAX calls. (Post timestamps are one of the few reliable API data points.) Get a zillion bright ideas about what else you could do with the API data. Go through more actual post data to catalogue all the inconsistencies you’d have to catch. Cry as Tumblr kills the dream you dreamed.

Project #4: Make the dread Tumblr beast FIX a thing

Create a script that runs on individual Tumblr blogs (subdomains of tumblr.com). Browse some blogs with various themes until you've found a post with the upside-down reblog-chain bug and a post with reblogs displaying normally. Note the HTML differences between them. Make the script detect and highlight upside-down stacks of blockquotes. Then see if you can make it extract the blockquotes and reassemble them in the correct order. At this point you may be mobbed by friends and acquaintainces who want a fix for this fucking bug, which you can take as an opportunity to bury any lingering doubts about the usefulness of your scripting adventures.

(Note: Upside-down reblogs are the bug du jour as of September 2019. If you stumble upon this post later, please substitute whatever the latest Tumblr fuckery is that you'd like to fix.)

Project #5: Regular expressions are a hard limit

I mentioned up above that Dreamwidth comments are good guinea pigs for user scripting? You know what that means. Kinkmemes. Anon memes too, but kinkmemes (appropriately enough) offer so many opportunities for coding masochism. So here's a little exercise in sadism on my part, for anyone who wants to have fun (or "fun") with regular expressions:

Write a userscript that highlights all the prompts on any given page of a kinkmeme that have been filled.

Specifically, scan all the comment subject lines on the page for anything that looks like the title of a kinkmeme fill, and if you find one, highlight the prompt at the top of its thread. The nice ones will start with "FILL:" or end with "part 1/?" or "3/3 COMPLETE." The less nice ones will be more like "(former) minifill [37a / 50(?)] still haven't thought of a name for this thing" or "title that's just the subject line of the original prompt, Chapter 3." Your job is to catch as many of the weird ones as you can using regular expressions, while keeping false positives to a minimum.

Test it out on a real live kinkmeme, especially one without strict subject-line-formatting policies. I guarantee you, you will be delighted at some of the arcane shit your script manages to catch. And probably astonished at some of the arcane shit you never thought to look for because who the hell would even format a kinkmeme fill like that? Truly, freeform user input is a wonderful and terrible thing.

If that's not enough masochism for you, you could always try to make the script work on LiveJournal kinkmemes too!

[webbygraphic001]

So, You’Ve Won An Exciting Redesign…What Now?

The transitioning of power is fraught with difficulties. Different teams have different values, different experience, different expertise, different priorities, and that leads to different tooling, and different methodologies.

It’s tempting to think of web design as an end-to-end process, starting with research and concluding with metrics. The reality is that most designers and developers join projects part-way through an ongoing process.

That leaves us with a difficult choice: do we try and meet the client’s expectations with our own toolset, or adapt to the tools and processes that are already in place?

For anyone who’s taking over a web project from a different designer/developer/agency (D/D/A), here’s a practical guide to help you make a success of the transition.

Step 1: Find Out What Went Wrong

99.99% of the time, something broke down in the previous client-D/D/A relationship.

In my experience it’s almost never about money. Most clients are willing to pay above the basic market rate if they believe they’re receiving a good return on their investment. A client that tells you the previous D/D/A is simply too expensive is anticipating negotiating your fees.

happy clients don’t shop around

Occasionally you’ll find that a freelance designer has been headhunted by an agency, and is no longer available. Occasionally the company outgrows a D/D/A, moving into areas that the D/D/A doesn’t support. But these situations are rare, happy clients — even moderately content clients — don’t shop around. If they’re speaking to you, something motivated them to do so.

It is alarmingly common that a D/D/A simply goes AWOL. It’s most common at the lower end of the market where the sums of money involved are less likely to prompt a legal dispute. Frequently, an unreputable D/D/A will ghost a client in favour of a better, newer opportunity.

Sometimes the client hires a new manager, and the new manager ushers in revised expectations that the previous D/D/A can’t meet.

Most commonly, the previous D/D/A has dropped the ball one too many times — mistakes happen, and reasonable clients will tolerate them provided they are rectified promptly, but everyone has their limits.

Most clients will be more than happy to explain what went wrong in the previous relationship; it will inevitably be a one-sided explanation, but it will help you to understand the client’s expectations.

Be extremely wary of a client who doesn’t know what went wrong. Be even more wary of a client who talks about “upgrading” their outsourcing — they’re trying to flatter you. In these cases the client may well be hiding something — like their failure to pay invoices.

Remember: at some point the previous D/D/A was new, and excited about having a new client, was optimistic about the project, and it didn’t end well. The best way to not repeat mistakes is to learn from them, and to do that you need to know what they were.

Step 2: Carry Out a Comprehensive Audit

We’re often so eager to secure new work, that we rush to have the client sign on the dotted line, expecting to be able to tackle any problems later.

It is imperative that as a professional, you keep your promises. Before you make those promises, take your time to understand the project and related business. If a client is invested enough to sign a contract with you they won’t mind you doing due diligence first.

Is There Still a Relationship With the Previous Designer/Developer/Agency?

Clients rarely have a full picture of their project — they’re not web professionals, if they were they’d be building their own sites. Your best source of information is the previous D/D/A.

Before you contact the previous D/D/A check with your client; it’s possible they don’t know they’re being replaced yet. If your client is fine with it, then reach out.

When you speak to the previous D/D/A be sensitive to the fact that you’re taking money out of their pocket. Certainly the previous D/D/A may tell you where to go, they may ignore you altogether, but most will be pragmatic about handing over a project if only to ensure their final invoice to their now ex-client is paid promptly.

Every site has its idiosyncrasies, if you can establish a friendly rapport with the previous D/D/A then the transition will be considerably less bumpy.

Who Controls the Domain Name(s)?

In my opinion a company’s domain name(s) should always be held by the company; it’s such an essential business asset that it should be guarded as jealously as the company’s bank accounts.

Unfortunately there are businesses that outsource everything to do with the web. If the break with the previous D/D/A is acrimonious then securing the domain name could be problematic.

It’s not your job to secure the domain name — you have no leverage, the client does. It is your job to impress upon the client how mission-critical the domain name(s) is.

Who Controls the Hosting?

Hosting arrangements vary from project to project. It’s not uncommon, nor unreasonable, for the previous D/D/A to be hosting the client’s site on their own space. If that is the case, be prepared to migrate it quickly either to your own server, or a dedicated space.

If you’re migrating onto a new space pay particular attention to the email provision. Taking over a project usually means taking over a live project, and that usually means email accounts.

In any case, you need full access to the hosting space. You certainly need FTP access, you probably need SSH access.

In addition to hosting, check if your client’s site uses a CDN, and if it does, who has control of it.

Backend Source Code

Once you have FTP access to the hosting server you can probably grab all backend code from the server.

The benefit of grabbing the code from the server — as opposed to accepting files from the previous D/D/A — is that you can be absolutely certain you’re getting the current (working) code.

If the client has broken with the previous D/D/A because they were unable to deliver on a particular task, you do not want to be working with files that have been partially modified.

Fresh Installs

If you’re working with something like a CMS, it’s often a good idea to run a fresh install on your server, and then copy across any templates, plugins, and migrate the database.

Frontend Source Code

When it comes to acquiring source code, frontend code is far more problematic than backend.

frontend code is far more problematic than backend

If the previous D/D/A is even part-way competent then the CSS and JavaScript on the web space is minified. Minified CSS is not too problematic and can be unminified fairly easily, but you do not want to be unpicking a minified JavaScript file — I once had a project in which a developer had minified his own code in the same file with all of his dependencies, including both Vue and jQuery [yes, I know].

Dealing with frontend source code can take on an additional dimension if you discover that the previous D/D/A used techniques you don’t — using Less instead of Sass, or writing scripts in TypeScript.

Unminifying CSS & JavaScript

Unminifying (or beautifying, or prettifying) code is reasonably easy. There are tools online that will help, including Unminify, Online CSS Unminifier, FreeFormatter, JS Minify Unminify, and more. You’ll also find plenty of extensions for code editors including HTML-CSS-JS Prettify for Sublime Text, and Atom-Beautify for Atom. You’ll find that some editors have the functionality built in.

A word of warning: code beautification does not restore comments, and in the case of JavaScript, does not unobfuscate variable names. Beautifying code is no substitute for a copy of the original, unminified source code.

Emergency Measures

If unminifying the source code isn’t possible for any reason, or more likely, the unminified JavaScript still looks like minified code — albeit nicely formatted minified code — then your last resort is to import the code and override it where necessary.

The first thing to do in this case is to explain the situation to your client. Make sure they understand this is a temporary patch that you’ll iron-out as you rebuild parts of the project.

Then, copy and paste the old minified code into a fresh project setup. For CSS that probably means creating a legacy.scss file, including the old CSS, and importing it into your own Sass. For JavaScript, create a legacy.js file, add all the old JS, and import that.

This will result in a much bigger set of files than necessary, you may end up using !important in your style declarations [yuck], and you’ll trigger lots of Lighthouse warnings about surplus code.

However, in the likely event that your client has a long list of changes they wanted live yesterday, this dirty hack will give you a working site that you can then rebuild piece by piece over time.

Assets

Assets normally means images, and images can normally be grabbed via FTP.

Occasionally — although less occasionally now image files rarely contain text — you’ll need the source files to make changes to images.

Whether or not the client has them, or if the previous D/D/A will hand them over, depends largely on the agreement between the client and the previous D/D/A.

Most businesses are reasonably aware of the importance of brand assets, so you’ll probably find they at least have a copy of their logo; whether it’s an SVG or a JPG is another matter entirely. Impress upon them the importance of locating those files for you.

Third Party Code

It is rare to receive a project that doesn’t rely on third party code. That third party code is probably entwined in the custom source code, and unpicking it is a time-consuming job.

It is very likely the previous D/D/A used a library or framework, and given the increasing number of them, it’s even more likely that the library or framework they used is not the one you prefer.

Whether you choose to unpick the code and swap out the previous D/D/A’s dependencies for your own preferences (usually faster in the long term), or whether you choose to work with what you’re given (usually faster in the short term) is entirely up to you.

In my experience it’s no hardship to pick up another CSS library; switching from one JavaScript framework to another is a substantially bigger job involving not just syntax but core concepts.

Beware Build Environments

Everyone has their own way of doing things. Some D/D/As embrace build environments, some do not. Some build environments are simple to use, some are not. Some build environments are adaptable to your process, some are not.

Unlike adopting a library, or even a framework, adopting a new build process is rarely a good idea

Build environments are numerous — Gulp, Grunt, and Webpack are all popular — and D/D/As are almost as opinionated about them as they are about CMS.

In lieu of raw files, it’s not uncommon for the previous D/D/A to tell you to “just run such-and-such CLI” command, to match up your local environment to theirs. Unlike adopting a library, or even a framework, adopting a new build process is rarely a good idea because you’re relegating yourself from expert to novice at a time when you’ve yet to earn your new client’s trust.

Stand your ground. Their approach failed, that’s why you’ve been brought in. You do you.

Who is Licensed?

Any third part code that has been paid for is licensed. Always check who holds these licenses. As well as being legally required, valid licenses are normally required for updates, bug fixes, and in some cases support.

Common pitfalls include: font licenses (which may be licensed under the previous D/D/A’s Creative Cloud, Fontstand, Monotype, etc. account); stock image licenses (which may be licensed for use by the previous D/D/A alone); and plugins (which are frequently bulk-licensed to D/D/As in bundles).

It’s depressingly common to find clients using unlicensed assets. On more than one occasion I’ve had to explain to a client the potential consequences of using pirated fonts.

Fortunately it’s increasingly common for third party providers to attach a licence to a specified domain, which means you may be able to claim the licence on behalf of your client. Major suppliers like CMS and ecommerce solutions frequently have an option for the previous developer to release a licence and allow you to claim it.

In the case of licensing, if you’re unsure, do not be afraid to reach out to the third party provider and check with them if your client is licensed once they break ties with their previous D/D/A.

The only thing that sours a client relationship faster than telling them they need to buy a license they thought they’d already paid for, is telling them they’re being sued for copyright infringement.

Protect your client, and protect yourself, by making sure everything is licensed properly. If you can get something in writing to that effect from the previous D/D/A, do.

Who Has the Research and Analytics?

One of the major benefits of taking over a site, as opposed to building from scratch, is that you have a measurable set of site-specific data to guide your decision making.

This only applies if you have the data, so ask to be added to the client’s analytics account.

There’s a strong chance that the design research carried out by the previous D/D/A is considered an internal document, not a deliverable, by the previous D/D/A. Check with your client: if they paid for the research (is it specified on an invoice?) then they’re entitled to a copy.

We Have a Blog Too…

Clients have a tendency to use the term “website” as a catch-all term for everything digital.

When you take responsibility for a website, you’re almost always expected to take responsibility for any digital service the client uses. That means, newsletter services like Mailchimp, customer service accounts like Intercom, and 227,000 page WordPress blogs that they forgot to mention in the initial brief.

Repeat the whole of Step 2 for every additional app, micro-site, blog, and anything else the client has, unless you are expressly told by the client not to.

Step 3: The Point of No Return

Up until now, you haven’t asked the client to sign on the dotted line. This whole process is part of your due diligence.

By checking these things you can identify unforeseen problems, and potential costs. Are you tied to an obscure build process? Do you need to relicense the CMS? Do you need to recreate all of the site assets?

Some of these conversations are hard to have, but the time to have them is now

If there is any question of the project being more complex than anticipated, have an honest conversation with your client — they will appreciate your transparency, and they’ll appreciate being kept informed. Any client who doesn’t value a clear picture of what they’re paying you for, isn’t a client you want.

Some of these conversations are hard to have, but the time to have them is now, not three months down the line.

This is the point of no return. From this point on, any problems aren’t the previous D/D/A’s, they’re yours.

Change the Passwords

For every service you have, from the newsletter login, to the CMS login, to the FTP details, change the password. (Make sure you notify the client.)

Set Up a Staging Site

You’re going to need a staging site so your new client can preview the work you’ve done for them.

Set the staging site up immediately, before you’ve made any changes to the code. In doing so you’ll discover early on if there are files missing, or issues with the files you do have.

Successfully Transitioning a Project

When a client commissions a site from scratch they are filled with expectation. The fact that they are leaving their previous D/D/A and seeking you out demonstrates that their experience fell short of their hopes.

You now have a client with realistic — perhaps even pessimistic — expectations. You have a benchmark against which your work can be objectively measured.

When problems arise, as they invariably will, never try to blame the previous D/D/A; it was your job to assess the state of play before you started work. If there is an issue with legacy assets, you should have brought it to your client’s attention early on.

If you learn from the previous D/D/A’s mistakes, you won’t be handing the project on to someone else any time soon.

  Featured image via Unsplash.

Source from Webdesigner Depot https://ift.tt/3n4FCg6 from Blogger https://ift.tt/2IgOcJI

[t-baba]

How to Bundle a Simple Static Site Using Webpack

Webpack has established itself as an indispensable part of the JavaScript toolchain. It has over 55,000 stars on GitHub and is used by many of the big players in the JavaScript world, such as React and Angular.

However, you don’t need to be using a front-end framework, or be working on a large-scale project to take advantage of it. Webpack is primarily a bundler, and as such you can also use it to bundle just about any resource or asset you care to think of.

In this article, I’m going to show you how to install and configure webpack, then use it to create minified bundles for a simple static site with a handful of assets.

But Why Would You Want to Do That?

Good question. Glad you asked!

One of the reasons for doing this is to minimize the number of HTTP requests you make to the server. As the average web page grows, you’ll likely include jQuery (yes, it’s still popular in 2020), a couple of fonts, a few plugins, as well as various style sheets and some JavaScript of your own. If you’re making a network request for each of these assets, things soon add up and your page can become sluggish. Bundling your code can go some way to mitigating this problem.

Webpack also makes it easy to minify your code, further reducing its size, and it lets you write your assets in whatever flavor you desire. For example, in this article I’ll demonstrate how to have webpack transpile modern JavaScript to ES5. This means you can write JavaScript using the latest, most up-to-date syntax (although this might not be fully supported yet), then serve the browsers ES5 that will run almost everywhere.

And finally, it’s a fun learning exercise. Whether or not you employ any of these techniques in your own projects is down to you, but by following along you’ll get a firm understanding of what webpack does, how it does it and whether it’s a good fit for you.

Getting up and Running

The first thing you’ll need is to have Node and npm installed on your computer. If you haven’t got Node yet, you can either download it from the Node website, or you can download and install it with the aid of a version manager. Personally, I much prefer this second method, as it allows you to switch between multiple versions of Node and it negates a bunch of permissions errors, which might otherwise see you installing Node packages with admin rights.

We’ll also need a skeleton project to work with. Here’s one I made earlier. To get it running on your machine, you should clone the project from GitHub and install the dependencies:

git clone https://github.com/sitepoint-editors/webpack-static-site-example cd webpack-static-site-example npm install

This will install jQuery, plus Slick Slider and Lightbox2 — two plugins we’ll be using on the site — to a node_modules folder in the root of the project.

After that, you can open index.html in your browser and navigate the site. You should see something like this:

If you need help with any of the steps above, why not head over to our forums and post a question.

Introducing Webpack to the Project

The next thing we’ll need to do is to install webpack. We can do this with the following command:

npm install webpack webpack-cli --save-dev

This will install webpack and the webpack CLI and add them to the devDependency section of your package.json file:

"devDependencies": { "webpack": "^5.1.3", "webpack-cli": "^4.0.0" }

Next, we’ll make a dist folder which will contain our bundled JavaScript:

mkdir dist

Now we can try and run webpack from the command line to see if it is set up correctly:

./node_modules/webpack/bin/webpack.js ./src/js/main.js --output-filename=bundle.js --mode=development

What we’re doing here is telling webpack to bundle the contents of src/js/main.js into dist/bundle.js. If everything is installed correctly, you should see something like this output to the command line:

asset bundle.js 1.04 KiB [emitted] (name: main) ./src/js/main.js 192 bytes [built] [code generated] webpack 5.1.3 compiled successfully in 45 ms

And webpack will create a bundle.js file in the dist folder. If you have a look at that file in your text editor of choice, you’ll see a bunch of boilerplate and the contents of main.js at the bottom.

Automating Our Setup

If we had to type all of the above into the terminal every time we wanted to run webpack, that’d be quite annoying. So let’s create an npm script we can run instead.

In package.json, alter the scripts property to look like this:

"scripts": { "test": "echo \"Error: no test specified\" && exit 1", "build": "webpack ./src/js/main.js --output-filename=bundle.js --mode=development" },

Notice how we can leave out the full path to the webpack module, as when run from a script, npm will automatically look for the module in the node_modules folder. Now when you run npm run build, the same thing should happen as before. Cool, eh?

Create a Webpack Configuration File

Notice how we’re passing the path of the file to bundle and the path of the output file as arguments to webpack? Well, we should probably change that and specify these in a configuration file instead. This will make our life easier when we come to use loaders later on.

Create a webpack.config.js file in the project root:

touch webpack.config.js

And add the following code:

module.exports = { entry: './src/js/main.js', mode: 'development', output: { path: `${__dirname}/dist`, filename: 'bundle.js', }, };

And change the npm script to the following:

"scripts": { ... "build": "webpack" },

In webpack.config.js we’re exporting a configuration object, which specifies the entry point, the mode webpack should run in (more on that later), and the output location of the bundle. Run everything again and it should all still work as before.

Including the Bundle

Now that we have webpack generating a bundle for us, the next thing we need to do is to include it somewhere. But first, let’s create a different entry point, so that we can list the assets we want webpack to bundle for us. This will be a file named app.js in the src/js directory:

touch src/js/app.js

Add the following to app.js:

require('./main.js');

And change the webpack config thus:

entry: './src/js/app.js',

Run npm run build again to recreate the bundle. Everything should work as before.

Now, if you have a look at index.html you’ll notice that there’s not much going on JavaScript-wise. At the bottom of the file we are including jQuery and a file called main.js, which is responsible for showing more information when you click the Read more… link.

Let’s edit index.html to include the bundle instead of main.js. Look at the bottom of the file. You should see:

<script src="./node_modules/jquery/dist/jquery.min.js"></script> <script src="./src/js/main.js"></script> </body> </html>

Change this to:

<script src="./node_modules/jquery/dist/jquery.min.js"></script> <script src="./dist/bundle.js"></script> </body> </html>

Refresh the page in the browser and satisfy yourself that the Read more… link still works.

Bundling jQuery

Next, let’s add jQuery to the bundle. That will reduce the number of HTTP requests the page is making. To do this, we have to alter the app.js file like so:

window.$ = require('jquery'); require('./main.js');

Here we’re requiring jQuery, but as we installed this using npm, we don’t have to include the full path. We’re also adding its usual $ alias to the global window object, so that it’s accessible by other scripts. We’re requiring main.js after jQuery, as the former depends on the latter, and order is important.

Alter index.html to remove the jQuery script tag:

<script src="./dist/bundle.js"></script> </body> </html>

Run npm run build and once again, refresh the page in the browser to satisfy yourself that the Read more… link still works. It does? Good!

Continue reading How to Bundle a Simple Static Site Using Webpack on SitePoint.

by James Hibbard via SitePoint https://ift.tt/3m9BoDq

[nsfmc]

A checklist for computer science undergrads

influenced by john regehr's 'basic toolbox' post about this topic, i thought i would throw my hat into the ring given that my experiences have been different than john's and seem to be at odds with what i have observed from working with many competent developers.

As i was leaving grad school, a friend of mine suggested to me that a winning strategy in Industrial Design had been to pick some medium that you worked well in and focus on doing all your work with that. The rationale here was that starting anew each project with a new medium invariably impacted the execution of the final deliverable distracting your prof/critic/peers from the high-level feedback you actually wanted on your work, creative vision, etc.

The advice there is to focus less on the tool and more on using a tool efficiently to communicate your ideas. In most cases it does not matter what the tool is as long as you can deploy it to solve problems in your domain.

Much of the tooling that exists in CS is directed at very specific users: working programmers. using these tools correctly as an undergrad is aspirational, but often their execution is distorted in academic contexts.

Every lab or workplace should expect to bootstrap new hires on internal tooling/workflows and almost none of them should assume prior knowledge. Depending on the aims, the only hard requirement should be ability to program in a language or framework similar to the one being used.

Core skills

A single programming language

You do not need to be ultimately proficient in every language, you just need to be able to sketch out and implement a solution to most problems you encounter in one language you enjoy working in. Which language you pick does not matter. If you are in john's classes, however, you should probably ensure that you know two languages: a compiled/systems-ey one (rust, go, c, java, swift, clojure, etc) and a scripting language (python, ruby, javascript, clojurescript, elm, mathematica, anything goes here as long as it has a repl or runtime that you can use to hammer out solutions to problems).

If you're not one of john's students, typically the scripting language will suffice (although it is generally rare to finish a cs program being exposed to only one language).

s/Text Editor/Touch Typing/i

The advice to be familiar with a text editor is largely a request from others who expect you to competently pair-program with them at their pace. The point of knowing an editor is much the same as knowing at least one language passably: it should not be something that gets in your way.

More essential than being comfortable with a specific editor (it honestly does not matter which one as long as you like using it and you are productive with it) is being comfortable touch typing. In the event that slack or other IM platforms have not made you a better touch typist, it is well worth investing time if only so that the act of writing anything is no longer a major time hinderance.

At some point, you may find yourself bored or in need of procrastination and decide you want to customize your editor: that is a perfect time to try something like sublime or atom or vi or emacs.

rough shell experience

you should be able to navigate around a filesystem, make directories, read directory listings and read the cli help documentation for most commands.

you absolutely do not need to know the details of your shell's preferences around glob expansion or how to write legible shell scripts. you can learn that, but after a certain point, all the obscure functionality ends up beng more "dev-ops" style knowledge that rarely pays any dividends except when developing commercial developer-facing internal tooling.

incidentally, getting students past the hurdle of commandline BS is almost certainly a job of an advisor (or postdoc). Ignoring it helps nobody and if a research project's documentation (q.v. below) is poor or nonexistent, the PI only has themselves to blame for this ongoing time commitment.

reading documentation

this is probably the weakest skill i have seen from folks coming out of undergrad. nobody expects you to know all of a language, all of its quirks, etc etc. what you are expected to know is how to find the answer to any reasonable question around your language or toolchain of choice.

A useful skill: you should be able to, given a stylized block of shell commands, paste those into your terminal one-by-one in order to bootstrap some project i.e. ./configure && make && make test. nobody should expect that you understand autoconf unless your research project is specifically devoted to it in some obscure way (i'm sorry if this is the case).

Specifically, you do not need to know how to parse an excel-formatted csv, but you should know where to look (or be able to find a solution) in order to do that in a reasonable amount of time. You do not need to know what an ideal runtime serialization format is for your language, you only need to call back on the terms you learned in your cs classes: marshalling, serialization, persistence, writing data, etc. although it can be useful at the extremes, be skeptical of the amount and quality of programming language trivia you know offhand.

writing documentation

no, this is not technical writing. this simply means you should be able to write a plain text file for each project that outlines

how to build some program

what its implicit dependencies are

what its arguments are

what the exposed/public api is

aside from being useful to others, in roughly six weeks or half a semester, this will invariably be of use to future-you as well.

a good acid test here is pointing a friend to the project and asking if they can build it and understand how they might use it. at some point you will embed this knowledge into a Makefile, shell script, or some other dsl, but until then it is infinitely more useful to write down the steps.

html

unless this is your job (or you intend it to be) you only need to know how to make an academic-level webpage which requires only the most basic knowledge of semantic html: h1, h2, ul/ol li, p, a, img, pre, strong, em (optionally hr, dl dd & dt). avoid css. if anyone gives you shit, you can invoke "Default Systems" giving you a perfectly valid excuse to stop devoting any more attention to design after you have mastered those tags.

reproducing errors

it is unclear when you are an undergrad or novice if you have encountered a truly exceptional case or if you simply have no idea what you're doing. Make a habit of reproducing and then writing down steps to reproduce edge cases you encounter and share them with people you ask for help from.

above and beyond, if you can identify the specific step (or code or whatever) that you invoke that (seemingly) causes the error, you will have an easier time teasing apart the nature of bug as you are telling someone else about it.

the most basic of data visualization skills

all this means is that nobody is actually good at doing this and everyone thinks that two hours peeking at ggplot2 has made them wizards at communicating the complexity of some dataset or results. it hasn't.

in many cases it suffices to be able to graph something from mathematica, R, d3, mathplotlib, or google sheets / excel. again, nobody cares how you do it as long as you do it and it doesn't take you all day. if your lab or workplace has some in-house style for doing this, they will need to train you how to do that anyway.

nonlinear spider-sense

the single reason "big o" notation is taught in school is so that at some point you can look at a performance regression and say "ha, that almost looks like a parab—o.m.g." the ability to recognize code or performance that appears nonlinear (or pathologically exponential) is probably one of the core things that i think undergrads should try to hone because during almost no other time will you be asked repeatedly, and at length, to explain the space/time complexity of arbitrary blocks of code.

computers are fast enough that you can usually be blasé about performance but eventually you'll start looking. being able to recognize something that is accidentally quadratic is often the most practical day-to-day application of cs theory—hone this spider sense.

Nice to haves

Version Control

there is a large chasm between "git for one" and "using git as a team" and that harsh valley is almost certainly due to the large amount of human communication and coordination required to work on a project as a team. Most people stress learning git, but this is largely useless advice because most of git or hg's corner cases and weirdness only come up when you're trying to integrate your work successfully among your teammates. It is good advice to perhaps become vaguely competent using git or mercurial or rcs, that experience will almost certainly pale in comparison to the massive flail when you are trying to set up multiple worktrees to create integration branches that contain the contents of multiple prs (each likely with their own rebase/merge/squash quirks).

to that end, you should learn to, say, create a commit and push your work, but everything else beyond that is almost certainly guaranteed to be complicated by whatever your team's workflow is (github prs, phabricator, gerrit, etc). i have rarely met people outside of professional or open source contexts that are capable of producing sensible chained commits or sane pull requests, it is simply not a skill that is required outside of contributing to open source or working on a commercial application. When people ask for git experience they secretly crave this flavor of professionalism that it took months to acquire at each of their prior jobs or internships.

A Presentation Tool

the baseline here is very low, you only need to be able to make a presentation and in all likelihood if you are still an undergrad, you easily have ten-plus years of doing this already. worry about fonts/design/transitions/etc once your content is solid.

most people produce terrible presentations making the needed baseline here quite low—it is more important that you know how to practice giving a presentation than it is to actually create the slides for it.

debugger knowledge

i have met many successful professional working programmers that have little to no idea how their language's debugging tools work. if you are a gdb wizard this sounds shocking on its face but lots of developers make do just fine without them. This is not to say that you should be willfully ignorant of debuggers or eschew them (especially if this is part of your curriculum), but nobody should look down on you if you learn (or are taught this) On The Job.

many of these tools are technically robust but have a ui only moderately less hostile than an opaque box of loose razorblades and chocolates. much like git, most developers internalize some form of stockholm affection for these tools despite their poor design, nonexistent editor integration, and often incomplete terminal support.

you should understand roughly what a debugger is and what it can (and can't) do, but it's almost certain that you won't need to have mastered debugger internals straight out of college.

build systems

this is honestly a "top of maslow" need. This is great knowledge if you are planning to distribute code or need it to build dependably/reliably on others' computers, it is absolutely inessential for an undergrad to understand to do this level of orchestration except as documentation for others to evaluate that your project actually builds etc etc. if your advisor or boss asks you to learn something like make or whatever, then by all means.

You should know what a make tool is for and when it is necessary, but you should not expect that to apply to the lion's share of work you do in school.

working for a period of time before asking for help

although this should be a core skill many adults are incapable of doing this effectively. there is a tradeoff between "i'm learning" and "i'm being unproductive." In an academic lab, arguably much of your experience will appear to be some quantum state that simultaneously inhabits both extremes but your goal should be attempting to independently arrive at a solution and after some time cut-off (which you should negotiate with your advisor/postdoc/pi/whatever) you should say "i tried $A, $B, and $C to accomplish $GOAL and was unable to make any progress because $ERR_A, $ERR_B, and $ERR_C."

even the act of noting down "what i am trying to accomplish, how i tried, what went wrong" may in itself lead you to a correct solution, but without having done that due dilligence and outlined those aspects, it will be difficult to receive good feedback from somebody that is trying to help you.

unit/integrated/etc testing

if you find that something like TDD is useful for you as a productivity or refactoring tool, keep doing that! most working software people cannot even agree on what the point of testing is, so it feels unfair to burden undergrads with this. in a professional context, you will be in a codebase with some established testing norms, you need only mimic those until you have determined what works for you.

there are lots of sane and sensible resources for writing tests or thinking about tests. understand that everyone does testing slightly differently so your best bet will be to figure out how testing plays a part wherever you go. in most cases, that codebase will have a specific incantation to invoke tests, your best bet is to ask how they do things there are just go from there if the setup is not obvious.

understanding scope

most academic projects are poorly managed because they have inconsistent pressure to be profitable beyond whatever funding inspired them. simultaneously, many academic advisors are not trained well to manage or lead a team (remember, most were hired to write grants and produce research papers (or possibly to teach)). management is something an advisor is literally picking up "on the job".

If you are unsure what exactly you are supposed to do, you should clarify as soon as possible what deliverable is expected and when it is due. This seems obvious, but because communication is complicated you may end up assuming you need to, for instance, resolve outstanding cli argument parsing bugs rather than only needing to add support for a new one. Understanding the scope of a project you've been assigned prevents you from doing redundant work or opening prs that will never get merged.

language idioms

If you are cozy with a programming language, the natural evolution here is to begin learning what idiomatic programming is like for it: what are common libraries, do people tend to program it functionally or imperatively, for or map?, what patterns are awkward or hard to read, what are common tools in its toolchain, how do people use it to write web services, how do people use it to avoid shell scripting, what are its peformance pathologies, etc. this is the extension to knowing how to read the documentation: it is developing intuition about the language to avoid doing counterproductive work in the future.

Many developers learn one language and become fluent in its quirks then proceed to apply those to every language they see later on. if you encounter this as a novice, it may appear that they are simply Better Programmers and not, instead, people who are speaking a pidgin-python with a heavy haskell accent.

To recap

It is something of a mistake to hope that a cs student will have the gradually developed and refined skills of a professional tradesperson. Graduating cs students often do not have strong professional software development experience (this is what internships are meant to accomplish) but are good at thinking about design/architecture. if, at the very minimum, as an undergrad you can churn out some ruby and have the runtime execute it, you're usually in great shape.

most cs programs do not train students to develop tightly crafted applications with industry-tested documentation/syntax/structure/workflows etc. bootcamps, however, do stress this sort of thing, which causes a confusing periodic wave of "college is dead, long live bootcamps."

when looking at job descriptions or other checklists, it's useful to try to gaze back at the abyss and ask "why was this listed here?"

John's research is compiler-focused, deals with undefined behavior, and often invokes llvm, c, and other "low level" toolchains. a strong undergrad cs student will be able to intern with john productively because the core of his research focus is mostly general to computer science: correctness, compiler behavior, etc. someone with deep knowledge of C, llvm, compiler design/internals, etc is almost certainly in a position to become one of his graduate students or postdocs. I think john's list is interesting, but i think it emphasizes details that are often foreign to developers at all skill levels.

finally this list is biased itself, so take it with a grain of salt: all my work experience is in design and frontend/backend web development and the skills listed here represent the qualities i've observed from successful interns and developers i have interviewed and worked with in the past ~ eight years. my experience is clearly n=1, but among the things i've noticed is that it's easy to get people to learn git, but it's hard to get somebody to internalize recursion, nonlinear growth, or canonical architecture patterns within the same time period. i'm not saying it's impossible, but if you're a cs student, this is 100% what the point of most cs programs is.

[geeksfromfuture-blog]

Can Technology Save Web Designers?

So is there a solution to the problem of web design? The answer is yes and it comes in the form of development tools. In its simplest form, an online project management system, as its name suggests, is an online project management system. Its application is mostly seen for its use in large companies. Large companies are traditionally known for their lengthy and long hours, often lasting days or even weeks. This has helped to create an ease in the management of projects within large companies. When these projects are handled with ease, it helps to get good quality of work out to the end user, resulting in success and satisfaction. With effective project management, projects would have better ideas that could easily be delivered to the right person with proper feedback. In turn, this would result in improved quality and better control over the project itself. The problem with this however is that most of the online solutions for web designers are really for the web designers in question. These tools mainly require much more than just designing. They require the designer to have a good understanding of web technologies in order to fully utilize these tools to their advantage. Designers need to understand the standard code formats, how the languages work, the use of fonts and also the various types of scripts. All of these are used to develop a website and each of these needs to be understood by the designer in order to make it work properly. If the designer does not understand these, then their job of designing will not be possible. While this would be fine for the designers, it is a disaster for the developers. As a developer, you have the tools to build websites and if your design is not designed properly, you will not be able to understand what is going on. As a developer, you should be able to use the information from the code and also the various types of codes, to design websites. Having too much knowledge about the web technologies is usually not a good thing. It would not be able to help the web designer in terms of building a website or even providing his services, as the designer would not be able to use it properly. As a result, these companies tend to offer less quality of service to their clients. A person without the ability to use the software would not be able to build a website. It may not be a big deal but a huge blow is the fact that this software tool can do more than just build a website. It can help to create a great looking website as well. It can help you develop a website that can reach a massive audience and in turn, would be able to earn more than a website built by someone without the ability to use this software. As such, a company that cannot provide a good design and effective services will fail. Using these tools will be a big help as the user will get an idea about what is needed, while at the same time, be able to make it work. The only drawback is that it may take a few tries before the user is able to get the hang of it. After all, this is what all newbie web designers have to face.

Will Technology Save Web Designers?

While many Internet marketing experts believe that Will Technology will soon change the face of the world, several companies argue that it is not possible. Here are a few reasons why they are wrong. Big companies can hire thousands of people just to do their job. However, the Internet allows individuals to grow their own businesses and hire more people for those purposes. Therefore, using technology to meet these needs will always be profitable. Because it is difficult to get workers who have the skills and education required to do a good job of work, the large corporations are constantly trying to hire people on contracts. Companies can hire workers whenever they want without needing to pay for their services. In the future, if the technology continues to improve and become more versatile, the next wave of the marketplace will not be in the workplace, but rather in the home. There are a lot of software packages and courses available to teach people how to do things like creating websites and learning the skills needed to promote them. So far, the Internet has proven to be a great way to teach, and it is unlikely that this technology will change anytime soon. People still need to learn about computers and Internet marketing. There are many web design jobs out there in the real world, and many of them can be done by people who know how to do Internet marketing. Most of the jobs done by people in the world will eventually move into the virtual world. What's the difference between that and advertising? It's not that people cannot market a product or service in the real world, it's that they need a bit more time, knowledge, and technical expertise. Will Technology will always be around because there is always demand for it. If you have any question, I have answered this and more. The technology is here to stay, and in the near future, we will see that the large corporations will be in business for themselves and will probably think twice before hiring those people who will be working for them in the future. As I pointed out earlier, that is not to say that those who are lucky enough to do the Internet marketing jobs will be the only ones working in the field. Some people's mind is not developed enough to go along with all the technology going on the Internet. The world is changing every day and will continue to do so. How long do you think it will be before someone can create a realistic looking website with no HTML coding? It will take time to get rid of all the skill sets that are required to do real world marketing in the Internet world. For now, those who are willing to learn will be able to use the technology as they have never used it before. Many people will never use the technology because they don't know about it, or they have no skills, or they simply do not have the time to do it. A lot of the things that the future companies need, they won't have. At the time when Will Technology saves web designers, it will be an interesting trend. However, as soon as the next economic downturn comes, a lot of people will be ready to buy what they did not have the time or skill set to create before. It seems that we have already reached the point where Will Technology will play a role in the future world of work.

Read the full article

[bedlamgames]

Q&A #65

Today legendary slavers, race assignments, cum, and an revisiting a topic that I suppose it was time for it to pop up again. 

Anonymous: is no haven a free download on here

Yes, absolutely! The base game will always be free to download. Only thing I’d say is that if you do want to support me that’s deeply, deeply appreciated and there’s an explanation of what the TF edition adds on the patreon. The other is that the update is very much due so you may want to wait a day or so before getting stuck in. 

valhallaimmortan: Is there going to be a way to recruit legendary slavers? Like once you reach a certain point a randomized legendary (special slavers from recruiter and etc.) Shows up and offers to run with you, but for a steep price that depends on how successful you are? And for some reason I'm always choosing dwarves if I need a smith even if it doesn't work like that... too many fantasy books where the dwarves were smith's... well anyways keep up the awesome work!

I enslaved one of my slavers, a Ogre that failed at the Quick as you Like mission but they are still showing up as a slaver and I get gold randomly from them leaving the encampment while they are enslaved. I can use Biomancy on them and I have already trained them to max level blow job training. That is a bug I'm guessing? And do some of the missions only count towards one set of traits? Because my slavers on random missions will only have the first slavers traits counted.

It’s funny you say that is that thanks to a patron request is that there’s an assignment in the very imminent update which has a unique slaver as a potential reward. Looking further ahead I’m planning to do certain races who will always be one offs due to their power/danger who will effect the whole encampment and you will need to consider whether it’s worth trying to recruit one or stay well, well away. 

Thanks for letting me know and will check em out. Assignment one sounds very odd though, any in particular as an example?

Anonymous: Hello! First off, love the game. Couple of bugs/thoughts (not sure where they fall into exactly). 1) When you promote a slave to a slaver, they always get the default [slaver] title, even if they might qualify for Hedge-Witch or Mistress or some such. Any chance that could be fixed? 2) There is something odd about aspects on promotions -- the region/assignment ones (Breaker, Aversol Dilettante) keep crowding out the better trait ones (Practitioner, Lay on Hands) -- any way to reverse that?

Thanks! I admit I’m torn on 1). On one hand it’s good as a shorthand as a quick reminder what the slaver is good at, one the other you can also see it as what they used to do before being a slaver, and in this case that’s being a slave. I think I’m going to leave it for now, but might change my mind on this one. As for 2) yes absolutely. Swapped some round a bit for the update. 

Anonymous: so some thoughts i had in the last few days, i played some other text based h games with quite some interesting mechanics, maybe they can find a place in no haven too; they play with the idea of changing not only the taste but also the effect of the cum in their game, some addictive, corrupting, some psychoactive and others simply alcoholic, the idea of addictive cum was topic in one ama so i thought these could be added in a whole new biomancy category? another thing, you said you will add

Addictive cum via orcs is a thing already, though corrupting cum has potential. Probably not biomancy but I’m planning on revisiting corruption soon and that’d be a good place to expand it from not just orcs. 

Anonymous: you said you will add a job to make tattoos, will this be a stylist like job? combinenthis job with biomancy or other magic to make some special looks/text flavour for hair/skin/limbs/mani and pedi features? not to mention the highly decorative tentacle options. on recent playthroughts in no haven i ve got the feeling that its

way too difficult to manage a small camp if you are looking for specific slaves, since slavers still focus on some slaves who need training, but them on guard and you have problems to send out parties for assignments, assignments, ignore them then they break your slaves. i get the feeling the need for gold and supplies is way too high at the start and way too low in mid and endgame, but that could only be me playing hardcore all the time :/ in short rebalance mid/lategame usage?

all in all keep up the good work, when will there be the next race specific assignment? after biomancer-update? or when will you start a new poll on the hypno thread for it? sry for the wall of text~~~

It is going to be a stylist encampment role. 

I do want to have decisions to make to manage resources in terms of slavers vs. filling roles. Saying that I do have plans to use gold for camp upgrades in various ways to help provide other options. 

There’s a race specific assignment this update. Not sure when I’ll next do a poll on that front, as I’ve got a couple planned already I’d like to do specifically, and I’ve still got some I should do from the last poll i.e doing something with Fallen. So maybe some time but not anytime soon. 

Anonymous: Have you considered doing something like a racial bonus? To me, the races of a fantasy world have distinct advantages over each other, and if say a dwarf had either an innate or a level up advantage to C:Me then the encampment role of metalworker is a lot less interchangeable, but dwarves feel more like dwarves.

There are already really, though I realise it’s backend this might not be immediately obvious. Every race and subtype has their own subtable of more likely traits, and there’s also various assignments where being of certain races gives bonuses. 

Saying that while there is weighting one thing I’ve always wanted to avoid is the ‘planet of hats’ so all races have the potential to do anything rather than being stuck to the stereotypes which is why there’s characters in the examine lore like the lamia scribe and the orc librarian. 

wowsupsexy:  Rags is just html and server functions and it get's crippled by font more then anything, you wouldn't want to see how it looks through a hex viewer though you were worried about being unable to code but rags just turns the input through it's horrid and clumsy ui into code just this one string here: Slaver Array(0)([v: Slavers able to return(0)([v: d4mult(0)(0)])])

Now I would suggest learning Ren'Py or Unity both would require work to learn just getting a ui with buttons and other nice things at first might seem daunting then theres the coding Ren'Py uses python (rather easy to learn) while unity uses C# at it's highest level can use a lot of other ones with it or near to none at all to start out with. Not saying you should just stop using rags right away but if you want something that's easier then being abused.

You might also be worried about not being able to carry over work that you've done already, I would mainly say that you should worry about that seeing as it should be clean to code or script in the fraction of the time it would require for rags even with copy and paste. Would be easier to hunt down bugs etc and if you're worried about encryption and protecting your work html isn't something to hide behind. Trying to get you to improve performance outside of removing the nice font colours.

This is tricky for me to respond to as this has come up repeatedly before, though if you’ve missed the various times this has come up with the same suggestions over and over again before that’s really no fault of yours as no one could be expected to follow all that but me. Believe me, I appreciate that you’re trying to help and any frustration you my notice in this is purely on my own end due to the situation I’m currently in I assure you. 

To try and TLDR as much as possible. Yes I know RAGS is awful. Tried Ren’py, not bad if you want to make a visual novel or use an existing framework, neither of which fits my games, and learning support for any other kind of game is near non-existent I found. Tried Unity, way, way over my head I admit last time I looked into it. Open to looking at it again the future. Did I mention RAGS is awful, but alas it’s what I know and believe me it’s far, far easier to fix bugs in something you know than something you’re still learning. 

To expand a bit more conversion is by no means as simple as making the suggestion. I’m now in my second year of converting Whorelock’s Revenge to Twine and while I’m more than happy to admit it’s not been my main focus, it’s slow, dispiriting work. Even with extracting code from RAGS and using a number of tricks to convert the code en masse it’s a messy process with many things needing to be sorted out and changed. Just that text setting variables being the wrong way round compared to what Twine needs for example takes an age to sort out alone. 

The main absolute number one thing though is that I need to be creating regular content cause a) that’s what everyone cares about, and without it I might as well just knock this all on the head entirely, and b) it’s much more interesting and engaging than re-doing old work. The two months I spent last year just doing Whorelock’s conversion were miserable to put it lightly, and the closest I’ve come to burning out. 

Saying that I do have a plan. Once the Whorelock’s Revenge conversion is done, I’m planning to slow down on No Haven for a while to expand that game as I’d originally planned before putting it on hold. Once I’m in the position to create new content for that game I’ll be in a much better place to look again at converting No Haven for which there are a number of options to explore, some I don’t even want to talk about as they’re not entirely under my sole control. 

[chicagoindiecritics]

New from Jon Espino on The Young Folks: Interview: Trey Edward Shults, Kelvin Harrison Jr., and Taylor Russell talk about the complexities in ‘Waves’

Every decade or so, we get new media that only entertains us but educates us on the experiences of the next generation. Many times they highlight the new complexities and differences of their experience to ours, but they also remind us that while it may be put in a different context, at its core they are things we have also gone through. Trey Edward Shults delivers exactly that in his latest film, Waves, which explores not only how these experiences affect a family unit, but how race can also play into them.

We spoke with Trey Edward Shults, and actors Kelvin Harrison Jr. and Taylor Russell collaborating together, revisiting their teenage years, MySpace and the start of social media, and more.

Since your first film, Krisha, you’ve created films that explore different family dynamics. We revisit topics like addiction and overbearing fathers. What attracts you to these types of stories?

Trey Edward Shults: I just connect to a lot of them. Personal experiences and loved ones’ experiences, especially in these 3 movies [Krisha, It Comes at Night, Waves] because they weren’t made that far apart. They were probably all brewing in the brain at around the same time. Whether it’s conscious or not, I think I was still rustling with some certain things, and remain fascinated by them.

As the film starts, everything seems almost idyllic, nearly perfect, but as it goes on, we learn the true complexity of each character. What was it about your respective characters that drew you in?

Kelvin Harrison Jr.: For me it was seeing this boy who had so much love and respect for his dad and those around him, but he really didn’t know how to communicate that or know what to do with that information for himself. He starts trying to appease everyone in a way that ultimately strips him away from his own identity and his own voice. I wanted to show the humanity of a black boy where he doesn’t fall into the cliches, but who can make mistakes that also don’t define who they are. I also wanted to show how a family would have to grow because of the historical traumas that come from being a black family in America right now. It wasn’t just about the character but also the entire message of what we have to go through as African Americans. 

Taylor Russell: It’s really rare that you get characters like this for a young woman. I haven’t ever seen a script like this come across my lap, so it was a no-brainer to be a part of it. To see a story that is so nuanced, truthful, and authentic to the complexities of the black experience, which is so vast and so different for every person, made me admire how that was portrayed in this story. I liked how quiet she was, and how her strength was unconventional and unique. Even the storytelling style was perfect, how it was told in the two halves, was something that felt unique and that I had never seen before. I knew Trey’s work from Krisha. It was shot in such a beautiful way and unlike any other cinema. People were telling me that it was going to be quite close to Krisha, and I was like, “Oh my god, if it’s going to be like that then hell yes! Let’s do it!”

I like the way the film is split into two different perspectives. The first half focuses on the male experience, while the second half follows the aftermath and the female experience. Was it always your intention to split the film up this way?

TES: I think it was in the DNA way before even writing it. It functions in dichotomies, literally from highs and low, white and black, male and female, love and hate, and everything else in between. I liked the idea of the movie functioning in these dichotomies, but what it’s really about is the link and complexity of how we’re connected by the contrasts in our lives.

Although the film mostly focuses on the individual struggles and the family as a whole, there are a few moments in the film that talks exclusively to the black experience in America. What resources did you use to research this before incorporating it into the film? 

TES: Kelvin was such an invaluable resource, and he’s the reason that the story is about a black family. We met on our last film [It Comes at Night] and first started talking about Waves. I didn’t have it written yet, but I started talking about ideas of what I thought the movies was, and broad strokes about what I wanted it to be. Then, we were like, “We should do it together.”  When I was first writing it, we were texting a lot. Almost like little therapy sessions as we were learning about each other, learning about our commonalities and shared experiences with families, especially around the character’s age. Kel got a first draft, 8 months before we started shooting and then we kept building it further and further at that point. I let the actors kind ad-lib and make some changes to the scenes so that it would feel more natural and authentic. I felt like it was my job just to listen and understand and try to capture everything I could. 

So this was truly a collaborative process?

TES: Oh, absolutely.

KHJ: It was so easy because it really feels like the script and Trey’s version of it really understands the family. It was like the skeleton and the muscles, setting a strong foundation so that we can come in and be like, “Well, let’s put some brown skin here and a little blush and we’re good to go.”  I was never fearful of speaking up and being like, “Well this is how I feel and this is how I experienced this.” He would also respond with, “Well that makes sense and I understand that so now let’s shoot it that way.” To me, that’s beautiful.

While watching the film, it takes a turn partway through where it turns into a horror film. It feels almost nightmarish at a certain point.

TR: On the day of shooting those scenes, you could tell right away the tonal shift the movie was taking. It felt scary, and that day of filming was really intense too. Although a lot of that was in the script, it is still quite shocking when you see the final version. 

TES: I talked about this with Sterling [K. Brown] a lot too. For this family, the greatest tragedy has happened and a nightmare has come to life. It started with exploring how this would feel for this family and this situation, and from there it grew to adding the visuals and audio elements that would end up giving it more of a horror feel. 

One of the things that really helped push some of the more unnerving elements was the sound design and Trent Reznor and Atticus Ross’ score. How did that come together?

TES: It just got super lucky. One day, I got an email from Trent and Atticus saying they were interested in working together. It was unbelievable. For sound design, I had Johnnie Burn and his whole team create that atmosphere and mood. 

I’m still haunted by the sounds of the ligaments and muscles tearing. It was almost like ASMR, but in the most stressful kind of way. 

TES: Johnnie had such an amazing foley team and I don’t even know how they got most of the sounds they used in the film. We played with that beyond just what would sound natural and tried out things that would be more subjective to the characters, like whenever Tyler would use his shoulder. 

KHJ: Oh, I was on the ground and I could definitely hear it and feel it.

Did you know how to wrestle or did you have to learn just for the role?

KHJ: Hell-to-the-no. I had to transform. I did 3 months of wrestling training. I did 3 days a week of CrossFit with wrestling twice a day. My wrestling coach Vlad is actually in the movie. He would tell me, “Kelly, get tough!”  It was a tough experience but ultimately great for the movie because I could feel free and authentic when playing the character. 

For some people, their teenage years are either the best or the worst. How did it feel revisiting that time for your characters, or even while developing this film together?

TR: I mean, we play teenagers a lot. I feel like I’m constantly in high school. Maybe I’ll finally graduate one day. One can only dream. I think I got a little bit longer because I have a babyface. This story though feels so transcendent beyond being a 16-year-old, it’s more about the human experience. In that way, it feels like it could be at any age. At the same time, it’s telling the story of teenagers and experiencing and feeling things for the first time. It was a fun thing to explore, but also a hard thing. 

KHJ: It was therapeutic for me. My parents saw it for the first time and they told me that that could really understand the relationships. That’s what the movie ends up being about: relationships. At the end of it, I was feeling like maybe I should call my mom and try to figure out how to communicate with her a little bit better. It transcends age in a lot of ways, but the specificity of the 2019 kid experience is fascinating to me. I remembering having MySpace growing up.  

I honestly still miss MySpace. It’s basically the only reason I have the limited HTML coding knowledge I have. I mainly miss that you could set specific songs on the page. 

KHJ: I don’t miss it at all. So many fights when you would set your top 5 or top 10. It was the beginning of proper social media drama, and I was just not interested in it. The intensity of that now with apps like Instagram and Snapchat is insane. 

TR: In the film, you see the role that social media plays after the major event happens. Just the way people comment and speak about it so realistic. Even the cussing in the movie feels real, like when Trey has the phone autocorrect “ducking” for the f-word. We all know about that and that feeling when you’re so mad that you just don’t even care that it typed that out because we all know what they’re trying to say. It just adds to the overall relatability and speaks to real experiences.  

from Jon Espino – The Young Folks https://ift.tt/2KVxHkE via IFTTT

from WordPress https://ift.tt/2XUzrQy via IFTTT

[defender-of-mankind]

Final Presentation and Write-Up

Intro to Game, Background, and Inspiration:

This is a first-person bug destroying simulator game. It’s called Defender of Mankind, and it is not influenced by any games I’ve ever played, I just thought it would be a fun game to make. Originally, this game was going to be something completely different. It was going to be more free-form, like an adventure game, but I quickly realized that making something to the scale that I was imagining in the time frame given would make it so the project wouldn’t end up the way I wanted it to. In the search for another concept, I ended up having a conversation with my dad about living in New York and how he always had cockroaches in his apartment. We both realized that it would make a pretty funny game, so I began developing on that idea more thoroughly.

Description of Prototype:

My prototype doesn’t actually differ that much from my original concept, and the only big thing that I can think of that’s different is the attack. I was originally going to have a character with arms and legs visible to the player so that the player could stomp on and hit the enemies, making it seem more realistic. However, I found the process of creating and animating the character to be very time-consuming and difficult with the little knowledge that I have about Unity and animating in the first place, so I decided to stick to a simple cross-hair in the middle of the screen and a click-to-kill function.

Another aspect of my original design document that I didn’t see fitting into this game was the idea of collectables. I originally wanted it so you could gain collectables that would increase the area of the light beam, but after going through with so much of the development, I realized that it wasn’t really plausible to include that on the basis of actually scripting it in addition to the idea of collectables not really working for the game concept.

The only other difference that didn’t really change, but I just didn’t include, is the actual background and “lore” of the game. Originally, the idea was that cockroaches are actually aliens sent to observe humanity and learn our weaknesses, and that’s why they can never die. The name of the game was based on this concept and there was going to be a final boss fight with a giant cockroach at the end that I knew wouldn’t make it into this prototype, but hopefully, as I keep developing the game and learning more, I’ll be able to get to that point.

While my prototype did hit most of the things I had planned on testing, there were actually more things that I had to add along the way in order for the game to make sense and function properly. These include the spawner system, the enemy counter system, the timer system, lots of UI, and the gameplay path (moving from the home screen to the actual game and from the game to the game over screen, etc.) to name a few.

Notable Gameplay Systems:

Probably the biggest issue that I faced with this project was the enemy movement. Obviously, I wanted it to look fairly realistic without making it over the top and having each leg or antenna move on all of the 200 enemy models, so I struggled with a lot of different ways to make the movement look realistic but simple. When I first started working on the enemy movement, I was SO hyped to even get them to move, and now looking at the project, I have come so far in literally just a week and a half of working on this system that it’s almost unbelievable. I still have to say, while I am satisfied with the enemy movement for the purpose of this prototype and the amount of time I had to develop it, I still wish there was a little more randomness to them and hopefully as I keep developing this game, that will be something that I can deal with. Overall, though, I’m really proud of how the enemy movement turned out.

Another system that gave me a lot of trouble was the spawners. I struggled for a long time with even how to get started creating the spawners for this game and went through a lot of different ideas and scripts to get to my final system. It’s still not perfect, one issue being that you still have to input the three coordinates for the actual spawn point, as I couldn’t figure out a way to link a game object’s transform position to the spawner and then be able to move the spawner and make duplicates without it messing them all up and having 200 bugs spawn from one single point (absolutely terrifying to see, by the way, even if it was only in a game). In the end, I got it to work out with only the little extra work of actually having to input the correct coordinates for each of the 12 spawners.

the one system that is essential to the game that I actually did not develop myself is the first person camera and controller. This was the first thing that I did, obviously, so I could start developing and testing the other systems, but I was so lost when I first started that I just used the first person camera controller from UNity’s standard assets package. This actually need dup saving me a TON of time and allowed me to move forward with the rest of the game that was actually part of the gameplay.

Testing:

I only had a few playtesters including my dad, sister, brother, roommates, and some coworkers. Everyone said they loved the game and were able to give me good insight into what to add and what I should explain more. This was really a crucial step towards the end of creating this prototype because after playing it myself for so long and knowing what everything did and how to make it do what I wanted it to, seeing someone else play the game allowed me to further explain what was needed and what I could take out.

Because of this, I ended up adding a text box to the game when you first start explaining that you have to defuse all the spawners and kill all the bugs. The other problem I noticed was that a lot of people skipped over the tutorial and then didn’t know the controls, but I’m not sure how to resolve that other than making the game path go from the main screen to the tutorial, but that seemed inconvenient if you already know how to play the game. In the end, I decided to leave it as is, with the tutorial as a separate path to take.

Final Touches:

After finishing basically everything on my list of things to get done, I decided to jump into something that I didn’t think I would have time for which was sound. From the beginning of this concept, I wanted to add bug sounds to make it creepier and more realistic. I found that the sound also helped as a cue so players were more aware of when enemies were spawned instead of just seeing the number of enemies go up in the corner of the screen. It was super creepy to code it all and make sure it worked, but I’m happy with how it turned out.

I also decided to add an intro screen with a brief introduction to the game. Initially, I wanted it to explain the whole concept of the world I created, but I decided to steer away from making it more complicated than it needed to be and just put 3 simple lines setting up the story and why the player is in this place. I also added more sound to this, having a skittering sound travel left and right across the canvas so that when you have headphones on it sounds like they’re moving from ear to ear. Super creepy but also sounds really cool.

After that, I cleaned up a few things, mainly making sure that the player doesn’t get stuck anywhere and moved some objects around to ensure that everything was spread out properly.

Finally, I decided to do some post-processing. This was a fun stage, and also very quick because I didn’t want to add too much and clutter the screen that already has so much going on. So I added a little bit of grain to make it creepier, some slight ambient occlusion to deepen the shadows, the smallest bit of bloom just because I wanted to see what it would do, and probably the most noticeable was the motion blur. I was actually really pleasantly surprised to see how the motion blur affected the player’s movement, making it seem jerky and almost frightened. It worked really well and I played with the settings a little bit to make sure it wasn’t overwhelming and distracting from the game.

After that, I built the game and called it done!

Conclusions:

There were so many things involved in this project that I never thought would come up, simply because I wasn’t totally aware of how the program works and what it actually takes to build a game. There were many times where I was beyond frustrated with a single line of code that just wasn’t doing what I wanted it to, but that made it so I had to take a step back and really look at the problem and think of various ways that I could solve it. Because of this, I actually learned way more than I ever thought I could learn about coding and about the Unity program in just 6 weeks.

My favorite parts of this project were creating the scene and learning a new coding language. In the past, I have taught myself how to code, mainly HTML and some basic CSS a few years ago, and I had to take MATLAB as a course last academic year, but learning C# was completely different from any language I’ve learned before. Through class time and scouring the internet for documentation and forums on why my code wasn’t working, I learned more about this language and how to make it do what I want it to do than I ever learned using MATLAB or any other language. I think the main reason for this is because I had something that I could reference back to and see if the change I made to the code actually made a difference to the game. I am a very visual learner and being able to see that my code changed part of the actual game was really cool.

Overall, I really enjoyed this project and learning so many new things that I know will apply to future projects. Having this class as the first one I take as an IDM major was a great experience and I can’t wait until I can start new projects and new classes.

Link to my Final Game Build: https://drive.google.com/open?id=18BBb_8o1MlSJ2FH2zIAfptmpwz8-s8qm

Link to Final Game Package: https://drive.google.com/open?id=1uDcZF6dnj6DQm3hac1Inb1JKUwb0craf

Link to my Final PowerPoint Presentation: https://drive.google.com/open?id=1nc1sGrmHPd98plYVTdMosV62VqggKCKA

[neshadavid]

Web Developer

Web design is definitely an enjoyable and fulfilling experience. It is a trade that mixes technical skills with creative ability. If you think confident with computer systems and also you enjoy creating documents, web design could be a terrific way to combine the 2 interests. For more information on omaha web developer, visit our website today.

That being stated, it certainly is overwhelming to think about learning a brand new skill. Before finding out how to be a web designer, you need to think about, "Must I be a web designer?"

I have been learning web design since i have was 10 years old, in 1994. Now i perform a large amount of web design personally as well as for some small company clients. There has been lots of pleasures, but additionally lots of frustrations. If you are thinking about being a web designer, there's something you need to bear in mind.

For those who have considerable time to dedicate to learning HTML, CSS, JavaScript and Illustrator, you can discover the basics over a couple of several weeks. Anticipate to spend cash on manuals, books, and applications.

Regardless of how you choose to learn web design and just how you choose to go into the field, many people have better possibility to become web designers than the others.

When you are programming, even when you are utilizing a simple language like HTML and taking advantage of a useful application like Dreamweaver, you are likely to encounter some frustrations. Sometimes, after i create an HTML document, I spend much more time making corrections and problem-solving than doing fun stuff. Do you want to spend considerable time testing and making little changes? Regardless of how you approach web design, boredom can not be completely prevented. If you are easily frustrated and frustrated, web design may not be for you personally.

Unless of course web design will probably be only a hobby for you personally, you'll have clients you need to use. Sometimes clients have lots of specific expectations. Some clients have knowledge about web design themselves, but others may demand things not understanding the technical limitations involved. Before you begin assembling your shed for clients, it is best to possess a thorough conversation together about what they need and what they desire. That can help you save considerable time. Would you like to invest days creating a website, simply to uncover that the client wants different fonts, colors, graphics, site organization and content? If you are getting into designing web pages for some individuals, you are going to need to anticipate to make lots of compromises and take lots of critique. Isn't it time for your?

Finally, think about if you possess the time to promote yourself. If you wish to be hired with a web design firm, additionally to learning skills and perhaps acquiring certifications, you've also should be prepared to pound the pavement together with your resume and portfolio. It could take you more than a year to locate a job. Anticipate to attend lots of selection interviews, and perhaps get lots of rejections.

If you are going to become freelancer, like I'm, you've really reached devote lots of energy to self-promotion. Generate a website, preferably with your personal domain. Anticipate to spend cash on advertising. Spend considerable time promoting the services you provide with social networking - Twitter, Facebook, Linked-In, and so forth. Scan classifieds, particularly online classifieds. Print business card printing and distribute them wherever you are able to. Make use of your connections and word-of-mouth to your benefit. Tell everybody you will know you are a web designer, and perhaps someone knows somebody that might be the first client. Sometimes I take more time promoting myself than I actually do really carrying it out itself.

If you are prepared to spend some money, perform a large amount of tiresome work, try taking some critique, and perform a large amount of self-promotion, then web design could be the field for you personally.

First, you need to start the training process. If you like classroom instruction and getting teachers, join some web design and graphic design courses using your neighborhood college. If you would rather start learning by yourself, buy good quality books, consider the source codes from the web pages you visit, and undergo some online tutorials. Even when you are likely to start learning web design inside a school setting, be ready to perform a large amount of learning inside your spare time, too.

You need to learn HTML, especially HTML5. Learn Cascading Style Sheets (CSS), as much as CSS3. JavaScript, possibly some server side scripting languages, and Flash are extremely helpful, too. Be sure to learn to use Illustrator. Without having the cash to purchase Illustrator immediately, begin by installing some free graphic design programs like Paint.Internet and GIMP. You can study a few of the basics of graphic design this way, and perhaps be much better prepared whenever you buy the newest form of Illustrator.

Nowadays, people connect to the web in additional ways than were ever possible before. When you are web designing, explore simply want to help make your web pages operate in multiple browsers, but additionally on multiple devices. Even fundamental mobile phones have access to the web today, not only smartphones for example BlackBerrys and iPhones. Even some gaming playing devices such as the The new sony PSP and Nintendo DSi have web browsers. Web surfers might be using small screens or enormous screens. They may be using a number of different browsers and versions of browsers. Users might have different plug-ins and fonts Flash is really a browser plug-in, for example. When you are learning web design, try surfing the web in as numerous ways as possible.

There are lots of useful sources for learning web design online, and you will find many useful online tools for web designers, a few of which I personally use.

The W3C is a superb starting point. They are the non-profit organization founded by Tim Berners-Lee, the person who began the planet Wide Web. The W3C sets standards for HTML, XML and CSS. Additionally to details about coding languages and standards, they've handy tools to validate your code.

HTML Goodies provides extensive excellent tutorials and articles.

I have many userful stuff here to date, but I am always learning more, and I'll continually be students of web design and media technology. As technology advances, things change. There's always new programming languages and applications. Learning is a continuing process. Want to know more about brooklyn web developer? Visit our website for more information.

Web design continues to be an interesting experience for me personally, and if you choose to enter into yourself to it, I think you'll work hard at it and also have an enjoyable experience.

[douglassmiith]

Smashing Podcast Episode 18 With Mina Markham: How Can I Learn React?

In this episode of the Smashing Podcast, we’re talking about learning React. What’s React like to work with, and how can experienced developers get started? Drew McLellan chats to Mina Markham to find out.

In this episode of the Smashing Podcast, we’re talking about learning React. What’s React like to work with, and how can experienced developers get started? I spoke to Mina Markham to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is a front-end architect, conference speaker and organizer, and lover of design systems. Her work on the Pantsuit patent library for Hillary Clinton’s Hillary for America presidential campaign marked a watershed for design systems within the industry and was featured on publications, such as Wired, Fast Company, and Communication Arts. Like many of us, she writes code for a living, currently as a senior engineer at Slack. So we know she’s a talented and forward thinking developer, but did you know she was once mistaken for Patrick Swayze? My smashing friends, please welcome Mina Markham. Hi Mina. How are you?

Mina Markham: I’m smashing.

Drew: Good to hear. Now, sometimes on the Smashing Podcast, we talk to people about the subject that they’re best known for. And sometimes it’s fun just to talk about something a bit tangential. Now, I could chat to you all day about pattern libraries, design systems, the amazing work you’ve done in that particular area, and I could talk to you about subjects that you’ve perhaps spoken about, events, such as the Event Apart, things like art direction. And we could obviously talk about CSS until the cows come home. But you tweeted a few days ago, and I realized that we’re actually both in the same boat in that we’re both experienced front-end engineers and we’re both recently started working with React. So before we get onto React itself, where were you coming to up to this point? Had you been working with other libraries and frameworks for JavaScript development?

Mina: No, actually I’ve been doing mostly vanilla JavaScript for a while. And before that, of course I got into JavaScript. Let me rephrase that. I started working with Java script using jQuery because it made the most sense to me. It was something that was very easily for me to parse to figure out what was happening. And then from there I backtracked to doing just vanilla, plain JavaScript, ESX, and I hadn’t really gotten too much into the framework wars. I had no, like I had no favorite. I had no dog in the fight. I was like, “For you, React, whatever. I don’t really care.” But times change.

Drew: And in this sort of way of working with vanilla JavaScript, because I’ve done a lot of that myself as well. I’ve worked with various frameworks. I’ve done a lot with jQuery back in the day. I worked with YUI, Yahoo User Interface Library. Had you felt many of the pain points that something like React’s architecture tries to address?

Mina: I don’t think I ever had. I spent most of my career making websites versus web apps and things like that. So everything I did was pretty static up to a certain extent. So I never really had to deal with state management, things like that. So the pain points that React attempts to solve I had never really applied to the kind of work that I did.

Drew: Generally speaking, what’s the sort of nature of the projects that you’ve with React so far?

Mina: It was actually only been the one project, which I’m currently working on and I can’t give away too many details because public company and all that good stuff.

Drew: Of course.

Mina: But essentially what I’m trying to do is I’m trying to use React to, it’s a very interactive sort of product where I need people to be able to enter in and save data at a certain state and then manipulate it and generate something else with said data. And that’s just something that it’s not simple DOM manipulation at that point. It really is a lot of more complex, front-end manage of data and managing the state of said data. So there really was no other alternative but to use some kind of library that attempts to solve that problem. I knew I wouldn’t be able to get past with just plain JavaScript. I contemplated maybe handling somethings on the server side, but again, due to the very interactive nature of what I’m working with, it need to be in the client. And so we already use React at Slack for various other things. And so I was like, “Okay, well we just should go ahead and adopt the same thing that the rest of the parent the companies are using and go from there.”

Drew: One of the things that I’m always seems to be a pain point with people picking up React is getting to grips with the tool chain that’s needed to get things working, Webpack being an obvious elephant in the room. Have you had to do much configuration of the tool chain or like me if you had the lUXury of teammates doing it for you?

Mina: Oh, I love the infrastructure team at Slack the data. The front-end infrastructure team at Slack, they handled all of that. I didn’t have to think about it. It was great. Because I tried to learn React before in the past. Usually the way I learn best is by actually working and implementing on things. And we use React to build a lot of hillaryclinton.com back in 2016. So it’s not like I’ve never worked with people who use it. It’s just my work never directly needed me to get involved. But that code base was very complex and very sophisticated, and there was so much happening that there’s such a barrier to entry to try to learn anything in there if you didn’t already know how React and RedUX and all of that works, which I didn’t. So I wasn’t really effective in learning in that environment.

Mina: Luckily, here I do have people to like take away a little bit more of the complex bits of it. I don’t have to worry about the Webpack config at all. That’s been set up. That’s been tried and tested and ready to go. I am in a similar boat where we also use RedUX in addition to React, which I didn’t realize were two different things. I didn’t know which part handled which. Dropping into a code base like that, it was a little disorienting because I didn’t realize that they were all the same thing. I had people who were seasoned React developers telling me, “Oh, we also are using RedUX, which makes it a little bit harder for you to really learn what React all can do if you’re starting from scratch.” And I never quite knew what they meant by that because I didn’t know what they were talking about.

Mina: To answer your original question, I am still having a little bit more of a little bit barrier to entry, because it’s not just learning React. I’m having to learn React and also how to use the RedUX store. So those two things at the same time can be a little much.

Drew: Yeah, I’ve found exactly the same thing coming into an existing code base as my first React project that uses RedUX. And I think as is the nature of any of these sort of technologies when they’re young, they iterate really quickly, and what’s best practice at one point, 6 months later has moved on and there’s a different way of doing things. And when you have a code base that spans many years, you can sometimes have different styles of implementing things in there. It doesn’t always keep sync. And of course, if you’re following a tutorial or whatever to learn, you’re reading books, you’re using resources, they will be in the most modern version of how to do things. And that doesn’t necessarily nit to what you see when you look at an existing, mature product. Is that something you’d experienced at all, or have you managed to keep your code base really up to date?

Mina: I think that is something that I definitely have been experiencing. When I tried to learn how to do React on my own, I looked at various tutorials and things like that. And I noticed, or at least people have told me who have worked who have been working with me that some of the things that we do or kind of anti-pattern or not quite how things work now, because this code base is slightly, well mature us relative, but it’s a few years old. And so there are some ways that I guess are easier to do things than the way we’re doing them currently because this was written years ago. So it’s a little bit of a treadmill trying to keep up with current times and make sure I want to do things the best way, but also I don’t want to break an established code base because I want to play around with stuff.

Drew: Obviously, one of the things with React that people like you and I are coming to it, it can feel a bit jarring as this whole thing with JSX. Are you using JSX in your project?

Mina: We are. I am using JSX.

Drew: Have you made peace with that?

Mina: I fell like a little small piece of me dies every time I open one of those files. It still feels sacrilege to put my HTML in the JavaScript file. I know that’s kind of revolutionary and the whole point, but it just feels off to me that I’m writing my markup in a JavaScript file. I’ve made peace with it, but every time I do it, I’m just like, “…” Separation concerns, it is a thing. I’d like it back, please.

Drew: It’s a valid point, isn’t it? My background when I was starting to work more seriously with JavaScript, and this was probably when I was back at Yahoo, things were very much on the model of server rendered HTML pages and then taking a progressive enhancement approach, layering JavaScript on top to enhance the interface. And if the state of something in the interface needed to change, your code had to know about all the parts of the interface that it needed to update, which obviously leads you to a tightly coupled approach with these big monolithic views where the code you write needs to know about all the other code around it. And I guess that doesn’t really lend itself to a componentized approach which you would take when working with a pattern library or a design system, which is more to your area of particular expertise. I guess, React lends itself more to that approach, does it?

Mina: I think it does, especially with the being able to couple the very specific CSS to one JSX or one React component. And so that way it makes it much easier to separate or only take what you need for the library and leave the rest, whereas a pattern library or design system that attempts to do something more monolithic with just one big style CSS file or something like that, it does make it a lot difficult. You kind of have to take it all or nothing. So I do appreciate that React allows us to do more individualized, more componentized way of development, even if I still wish there was a way for me to do truly separate my presentation layer and my content layer from my interactivity layer. But maybe that’s just me being a little bit old school in that sense.

Drew: I definitely feel the pain there. The idea is that, come and correct me if I’m wrong, my understanding is that rather than separating the technologies, the CSS, and the JavaScript, and the HTML, it’s separating the functionality. So everything that is one component all exist together-

Mina: Yeah.

Drew: … which I guess is useful if that component then is no longer needed. You can just delete it, and it’s gone, and it doesn’t leave a footprint around your app. That’s not always the case with CSS though. How are you working with CSS with React? Have You looked at things like styled-components or anything like that?

Mina: No, we haven’t. I’ve heard of styled-components, but I’ve never quite really investigated them very fully to be perfectly honest. So the way that we’re working with CSS with React is we write Less, and we just have a Less file attached to each individual component that gets imported into that component. And then it gets bonded up via Webpack and served to the client.

Drew: Are you using a system like BEM or something to turn namespace?

Mina: Yeah. We’re using BEM for namespacing, although the adherence to it is kind of varied depending on who’s writing what. But we try to use a BEM namespacing pattern to make it a little bit clearer what the purpose of each individual class and component is.

Drew: And does that seem to be working successfully for you?

Mina: I think so. Occasionally it kind of has the same old problem of I sometimes don’t know how to name something. After a while daily things has always and will always be a difficult thing for master. So that’s the only issue I have with is I occasionally I have no idea what I should call a particular component.

Drew: Definitely. That’s a constant battle, isn’t it, how to out the name things?

Mina: Yeah.

Drew: I always end up when working on a new feature or something like that, you give a component and all the classes and everything the name that the feature has got at the moment. And then by the time you come to launch, it’s been renamed something else. So you have references to the old name in the code and the interface has the new name. And …

Mina: I try to always name things based on the function or the purpose of it versus things that are a little bit more ephemeral, because it’s less likely that the actual purpose of this component will change. I forgot to mention, but in addition to using BEM, I guess we use BEMITs if you’re familiar with that. It’s basically the ITCSS plus BEM, both of which were created by Harry Roberts. So I use Hungarian notation to denote whether or not something is a component, versus a layout object, versus like a larger pattern comprised of multiple components. And then from there we use the BEM convention to signify like the block element and all that.

Drew: And have you had to do much refactoring and deleting of components and things in your code base and had to deal with the issue of CSS getting left behind?

Mina: Yeah. So the non-React part of my job, of maintaining slack.com is that’s all just a bunch of Less files that are being compiled for CSS. And I guarantee you, there’s a lot of zombie code in there, because we definitely iterate above things a lot in the time I’ve been there. And we don’t always have time to go back and do the cleanup versus when we redesign a page or something. So it’s overdue for an audit, I’ll say that.

Drew: This is something that we’ve just been looking at in our React project, looking at how we approach CSS. At the moment, we have a few big, global CSS files for the whole of the app, and we do get this situation where our bundle size is just growing, and growing, and growing and never gets any smaller, even though things do get removed. So we’ve been looking at things like styled-components, Tailwind as well is another option that we’re really seriously considering. Have you looked at tailwind much?

Mina: I haven’t looked at it a lot. I’ve been curious about it, but again, I’ve never really had time to dig in to actually see if it’s something that I want to try to bring into our code base.

Drew: I was actually quite surprised, because like you, I’m a bit old school with how to do these things. I like nice separation of concerns. And I like to write my CSS in CSS, and of course the approach with Tailwind is you have all these class names, which feel a bit like inline styles that you’re applying. And if it feels dirty.

Mina: Yeah.

Drew: And I volunteered within the team, we each which took a technology to investigate if they’d be a good fit for our problems, and I volunteered to look at Tailwind because I was absolutely certain I was going to hate it.

Mina: No, no.

Drew: But it turns out I actually think it solves a lot of problems. I was quite impressed.

Mina: Yeah. I’ve sort of come around to a similar way of thinking, because I in the past would much prefer to have one class comprise all of the styles I needed for a particular component and not do a class per property, as I believe Tailwind does or languages like it do. For the similar reasons, it felt very much like, “Well, I’m just running inline CSS at this point. Why would I do this?” But as I’ve been developing more and more, inside of our Slack design system, I created a bunch of what I call utility classes that do things like add a bit of margin with a pattern. I’ve noticed that more and more, I’m using those classes in addition to the component classes. So I’m like, “Okay, well maybe I should revisit this whole to doing a CSS as a one declaration at a time.” I don’t know if I’d go that far, but it’s definitely worth considering.

Drew: Computing seems to flip flop in terms of trends between thin clients and fat clients solutions. We started with mainframes with terminals, and then the PC era with windows and office and all these sort of big applications. And they were all getting really slow, and than the web came along, and that was just a browser, and all the work was being done on the server. And it was all fast and snappy again. And now we’ve gone back to putting all that work back in the browser with everything being done with JavaScript, things like React and the JAMstack approach where we’re back to a sort of fat client. I sometimes worry that we’re asking too much of the browser. Is this a mistake? Are we asking too much of the browser trying to do all this stuff in React?

Mina: I want to say yes with the caveat of, again, my experience is very much contained to mostly static websites. I don’t do a lot of product development. So maybe in that realm, this makes more sense. But from my perspective, I feel like we’re a lot of the times using a hatchet when we just need a butter knife. I don’t know why we need put all this in the browser, put so much work and so much pressure on the client. I feel like we could do this much simpler. One of the things that always made me a little hesitant to use React, or I say hesitant, but what I mean when it made me viscerally angry and I actively opposed, was when I would go to a website and literally nothing would render because there was one error or something, Like, “Really? The entire page is broken because one function broke down?”

Mina: It just kind of annoyed me that a lot of times it was an all or nothing approach. One of the talks that I gave at AEA in the past and other places in the past was talking about how to include progressive enhancement and not just your development, but also of art direction and design of sites. And I would point out specifically examples of websites that didn’t do progressive enhancement or any kind of graceful degradation. It was like either you have the JavaScript running in the browser or you get absolutely nothing. And it would be like just a simple site that represent information about the history of web design, which was one of the sites actually talked about, the history of web design from like 1990 until now. It was a beautiful website with lots of timelines, animation of things. But it also could have been rendered statically with just a list. There were steps in between showing nothing and showing that beautifully enhanced experience that I think got lost because of the way we’ve been approaching modern web development now.

Drew: So would you say there are absolutely some categories of projects that suit a solution like React and some where it really shouldn’t be used and you should be using more traditional methods?

Mina: I think that if your site particularly is mostly static, it was just serving up information, I guess I don’t understand why you need a project like React to render something that doesn’t have a lot of interaction beyond just DOM manipulation. I guess I don’t see what benefit you get from that. Again, I may not be working on the appropriate projects. I may not just have seen or found that use case, but I’m having a hard time seeing if it’s just mostly static site, presenting content, not a lot interaction, not a lot of interaction beyond manipulated DOM and doing animations. I don’t see how having a React library helps you accomplish that goal.

Drew: It’s interesting because I’m not bad talking it because I haven’t actually used it, but I see a lot of Gatsby projects and Gatsby being a static site generator that uses a React front-end in it. And I see all the examples of the themes and things they have available are all content based sites, or blogs, and a recipe site, and a portfolio, and these sort of things. And there’s something I think actually that this isn’t necessarily the right fit for something like React. Why isn’t this being statically rendered and then progressively enhance?

Mina: Yeah.

Drew: It’s not software.

Mina: Yeah. I haven’t actually used Gatsby either. I’ve heard plenty of great things about it, but that’s probably one of the examples I would think of where I’m like, “Okay, I guess I’m just not seeing why that tool is necessary to do that particular job.” Again, I don’t know. Maybe it’s just because more people are comfortable writing in React when they are writing new something else, and it’s just providing a tool that meets people where they are. I’ve heard great things about static site generators that use React for people who have used them and love them, but it’s not a use case that I would have immediately been like, “Oh, that makes sense.”

Drew: It seems like there’s always been this battle between what we would call a website and what you might call a web app. And the chasm between the two seems to be getting wider, and wider, and wider, whereas a progressive enhancement approach tries to bridge the gap by taking something static and adding JavaScript and adding interactivity. It seems that things like React are ideally suited for software that you’re running in the browser. Would you agree with that?

Mina: I would definitely agree with that because it feels like it’s was built for that type of environment; it was built for running software. It was built by Facebook for Facebook. So it was built for a product. It was built for running whatever you call a web app in the browser and not necessarily for the type of work that, as I mentioned, I’m used to doing. So I think in those scenarios, it definitely makes a lot of sense to use it if you’re building a more complex, more sophisticated piece of software that’s meant to run inside of a browser. But if you’re building a marketing agency site or whatever, I guess I would still struggle to see why it will be necessary there.

Drew: So are we giving people permission to still build decent, statically rendered websites?

Mina: I would love to see more of that happen. I feel like that’s kind of gotten lost and it’s sort of lost its, if it ever was cool or whatever. I feel like we’ve lost that part of web development. It’s so funny: you and I both said that we’re kind of old school, and I laugh at that because I’ve actually been doing web development for, what, six years now? How am I old school? It hasn’t been that long for me. And yet somehow I’m part of the old guard who doesn’t like new and shiny things. I don’t get it.

Drew: So in fact React has actually existed for the whole time that you’ve been a web developer.

Mina: Maybe I just have an old soul. I don’t know.

Drew: I think that’s probably the case. I’ve not looked personally at, there are service side rendered approaches you can take with React apps. Have you experienced any of those?

Mina: I haven’t experienced any them. I briefly looked into them for the project I’m currently working on, because I feel like there’s parts of the operation that would work better on a server versus in the clients. But I think because of my limited knowledge and the fact that the code base is a little more complicated than I can understand, I wasn’t quite able to figure out how to make that part work. I would love to figure it out eventually, but I spent a day digging into it. I was like, “You know what? I’m not grokking this away I need to be. So I’m just going to back up and take a different route.”

Drew: Yeah. I think we’ve all been there.

Mina: Yeah. I went down a path. I was like, “Oh, this is dark and scary. Let’s reverse. Let’s reverse.”

Drew: Step away from the code.

Mina: Yes.

Drew: So you’ve been very diplomatic and polite about React so far. I sense that there’s some tension bubbling under the surface a bit. Come on. Tell us what you really feel.

Mina: I have been polite and diplomatic, mostly because the Reacts fan base can be a little mean sometimes, and I would rather not have them come for me. So please, React is great. It’s wonderful. Use it for what you want to use it for. I kid, but even that tweet that you mentioned at the beginning of this podcast where I think what you said is that I don’t hate it. I don’t love it, but I don’t hate it. Even that statement, I got people, there was no vitriol, but it was more they where ready to leap to the defense and say, “Well, I love it because X, Y, Z.” I’m like, “I didn’t say it was bad. I just said that I’m meh about the whole thing.” But apparently being meh is not okay. I have to love it.

Mina: So that’s why I probably have been a bit more diplomatic than I would ordinarily be, just because I don’t want people to think that I’m bad mouthing it, because I’m not. It has a place in more web development. It serves a function. It does its job well. People love it. It’s just not a tool that I’ve ever had or wanted to use until now.

Drew: Yeah. Things can get very tribal, can’t they, with people feeling like they have to take one side or another, and you’re either absolutely for something or absolutely against something? And I’m not sure it serves a good purpose, and I don’t think it really moves us forward as an industry and as a community to do that.

Mina: Yeah. It’s really odd. It’s fascinating to watch from just a sociological standpoint, but it’s often just really like weird to observe. It’s like I’m not allowed to just be, like I said, neutral about certain things. I have to have a strong opinion, which is I don’t think healthy. What’s the term, “Strong opinions, loosely held?” That’s kind of the way I go about things. I feel strongly about certain things, but it’s not like you can’t change my mind. Where I feel like some people, their identity gets wrapped up into certain aspects of it ,that if you are not for whatever they’ve chosen to identify with, it’s a personal slight versus just, I don’t care about this particular topic, or tool, or whatever.

Drew: Yes. I don’t know if it’s made worse by the fact that we all are sort of tending to specialize a lot more in particular parts of the stack. And I know there are people who are React developers. They would call themselves a React developer because that’s what they work in. And they wouldn’t necessarily write any vanilla Java script or wouldn’t use Vue or whatever. React is their world. So I guess it almost feels like an attack on their entire career to say, “I don’t like React.” Well, they’re really invested in making you like React or whatever the technology may be.

Mina: I will admit to being one of those people in the past. Actually, probably it was mostly about SASS, I believe. I was very much on the team of doing SASS as a preprocessor and all other preprocessors are trash. I don’t want to talk about them. I don’t want to deal with them. And I realized that was a very narrow way to look at things. Use the appropriate tool for the job. Whatever makes you more productive, that’s the right tool. It doesn’t really matter what it is.

Drew: Are there any technologies that we work with that don’t have that sort of tribal feel? Is there anything that people are just happy to use or not use? I can’t think of anything.

Mina: Wow. No one has opinions about markup, actually.

Drew: No.

Mina: I feel like no one has opinions about like actual HTML and just markup, just like, “It’s there.” They use it. But people have strong opinions about CSS and how it’s either terrible or wonderful, and the preprocessor wars that don’t really happen all that much anymore, and then of course, all of the tribalism within the various JavaScript libraries.

Drew: So you would say your journey so far with React is still just, “It’s a tool. It does its job?”

Mina: It went from a curiosity to active and visceral dislike because of how prevalent it was and how I unnecessary I thought that that prevalence was to meh. I’m now with meh, which again does not mean I hate it. It just means …

Drew: I think that’s a good place to be. I think we’re probably all sort of stronger as technologists if we understand the value of a particular technology for its purpose. We can evaluate what is good for what circumstance and pick the right tool for the job.

Mina: Yeah. And that’s kind of where I’ve arrived at this point in my career where I don’t get really invested in any particular language, or technology, or whatever, because it’s like, “Just whatever tool is most appropriate for what you’re trying to do, then use that.” I’ve learned that there’s a place for everything; there’s a time and a place to do everything. And up until recently, there was no real time or place for me to use this React librarian, and now there is.

Drew: I think that’s a good place to be. So I’ve been learning all about React lately as you have in the day job. Is there anything else that you’ve been learning about lately?

Mina: I’ve actually learned ironically, which is I think another language that has originated at Facebook, I’ve been doing a lot of Hack development, mostly because that’s what I use at Slack, at my day job. Learning Hack paved the way for me to get more comfortable using React because they follow very similar patterns, except one is server side and one’s not. So that, along with just in general, I’ve been learning more about the back-end and how that works for various different reasons. And I’ve been stretching myself for the past couple years and getting more and more outside of my comfortable zone. Design systems, libraries, that’s very much my world, and I feel very good and comfortable in that world. But I’m stepping outside of it and doing a lot more server side logic, and API development, and data modeling, and all of that. I’ve been doing a lot on that for the past year as well.

Drew: I find that the more I understand about the whole stack about back-end stuff in front-end stuff, each one helps my knowledge of the other. I find I write better front-end code by having written back-end code and understanding-

Mina: Yeah. I think I feel the same way. Now that I have a better idea of, like we said, the whole stack of how we get from the data to the end client. I find that I’m thinking about the entire pipeline no matter what part I’m actually working in. I’m thinking about what’s the best way to structure this API so that when I get to the template, I don’t have to do so much manipulating of the data that I receive on that end of it. It’s definitely made me overall a better engineer, I feel like it

Drew: If you, dear listener, would like to hear more from Mina, you can follow her on Twitter where she’s @MinaMarkham and find her personal site at mina.codes. Thanks for joining us today, Mina. Do you have any parting words?

Mina: Have a smashing night?

Drew: Great.

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

Via http://www.scpie.org/smashing-podcast-episode-18-with-mina-markham-how-can-i-learn-react/

source https://scpie.weebly.com/blog/smashing-podcast-episode-18-with-mina-markham-how-can-i-learn-react

[laurelkrugerr]

Smashing Podcast Episode 18 With Mina Markham: How Can I Learn React?

In this episode of the Smashing Podcast, we’re talking about learning React. What’s React like to work with, and how can experienced developers get started? Drew McLellan chats to Mina Markham to find out.

In this episode of the Smashing Podcast, we’re talking about learning React. What’s React like to work with, and how can experienced developers get started? I spoke to Mina Markham to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is a front-end architect, conference speaker and organizer, and lover of design systems. Her work on the Pantsuit patent library for Hillary Clinton’s Hillary for America presidential campaign marked a watershed for design systems within the industry and was featured on publications, such as Wired, Fast Company, and Communication Arts. Like many of us, she writes code for a living, currently as a senior engineer at Slack. So we know she’s a talented and forward thinking developer, but did you know she was once mistaken for Patrick Swayze? My smashing friends, please welcome Mina Markham. Hi Mina. How are you?

Mina Markham: I’m smashing.

Drew: Good to hear. Now, sometimes on the Smashing Podcast, we talk to people about the subject that they’re best known for. And sometimes it’s fun just to talk about something a bit tangential. Now, I could chat to you all day about pattern libraries, design systems, the amazing work you’ve done in that particular area, and I could talk to you about subjects that you’ve perhaps spoken about, events, such as the Event Apart, things like art direction. And we could obviously talk about CSS until the cows come home. But you tweeted a few days ago, and I realized that we’re actually both in the same boat in that we’re both experienced front-end engineers and we’re both recently started working with React. So before we get onto React itself, where were you coming to up to this point? Had you been working with other libraries and frameworks for JavaScript development?

Mina: No, actually I’ve been doing mostly vanilla JavaScript for a while. And before that, of course I got into JavaScript. Let me rephrase that. I started working with Java script using jQuery because it made the most sense to me. It was something that was very easily for me to parse to figure out what was happening. And then from there I backtracked to doing just vanilla, plain JavaScript, ESX, and I hadn’t really gotten too much into the framework wars. I had no, like I had no favorite. I had no dog in the fight. I was like, “For you, React, whatever. I don’t really care.” But times change.

Drew: And in this sort of way of working with vanilla JavaScript, because I’ve done a lot of that myself as well. I’ve worked with various frameworks. I’ve done a lot with jQuery back in the day. I worked with YUI, Yahoo User Interface Library. Had you felt many of the pain points that something like React’s architecture tries to address?

Mina: I don’t think I ever had. I spent most of my career making websites versus web apps and things like that. So everything I did was pretty static up to a certain extent. So I never really had to deal with state management, things like that. So the pain points that React attempts to solve I had never really applied to the kind of work that I did.

Drew: Generally speaking, what’s the sort of nature of the projects that you’ve with React so far?

Mina: It was actually only been the one project, which I’m currently working on and I can’t give away too many details because public company and all that good stuff.

Drew: Of course.

Mina: But essentially what I’m trying to do is I’m trying to use React to, it’s a very interactive sort of product where I need people to be able to enter in and save data at a certain state and then manipulate it and generate something else with said data. And that’s just something that it’s not simple DOM manipulation at that point. It really is a lot of more complex, front-end manage of data and managing the state of said data. So there really was no other alternative but to use some kind of library that attempts to solve that problem. I knew I wouldn’t be able to get past with just plain JavaScript. I contemplated maybe handling somethings on the server side, but again, due to the very interactive nature of what I’m working with, it need to be in the client. And so we already use React at Slack for various other things. And so I was like, “Okay, well we just should go ahead and adopt the same thing that the rest of the parent the companies are using and go from there.”

Drew: One of the things that I’m always seems to be a pain point with people picking up React is getting to grips with the tool chain that’s needed to get things working, Webpack being an obvious elephant in the room. Have you had to do much configuration of the tool chain or like me if you had the lUXury of teammates doing it for you?

Mina: Oh, I love the infrastructure team at Slack the data. The front-end infrastructure team at Slack, they handled all of that. I didn’t have to think about it. It was great. Because I tried to learn React before in the past. Usually the way I learn best is by actually working and implementing on things. And we use React to build a lot of hillaryclinton.com back in 2016. So it’s not like I’ve never worked with people who use it. It’s just my work never directly needed me to get involved. But that code base was very complex and very sophisticated, and there was so much happening that there’s such a barrier to entry to try to learn anything in there if you didn’t already know how React and RedUX and all of that works, which I didn’t. So I wasn’t really effective in learning in that environment.

Mina: Luckily, here I do have people to like take away a little bit more of the complex bits of it. I don’t have to worry about the Webpack config at all. That’s been set up. That’s been tried and tested and ready to go. I am in a similar boat where we also use RedUX in addition to React, which I didn’t realize were two different things. I didn’t know which part handled which. Dropping into a code base like that, it was a little disorienting because I didn’t realize that they were all the same thing. I had people who were seasoned React developers telling me, “Oh, we also are using RedUX, which makes it a little bit harder for you to really learn what React all can do if you’re starting from scratch.” And I never quite knew what they meant by that because I didn’t know what they were talking about.

Mina: To answer your original question, I am still having a little bit more of a little bit barrier to entry, because it’s not just learning React. I’m having to learn React and also how to use the RedUX store. So those two things at the same time can be a little much.

Drew: Yeah, I’ve found exactly the same thing coming into an existing code base as my first React project that uses RedUX. And I think as is the nature of any of these sort of technologies when they’re young, they iterate really quickly, and what’s best practice at one point, 6 months later has moved on and there’s a different way of doing things. And when you have a code base that spans many years, you can sometimes have different styles of implementing things in there. It doesn’t always keep sync. And of course, if you’re following a tutorial or whatever to learn, you’re reading books, you’re using resources, they will be in the most modern version of how to do things. And that doesn’t necessarily nit to what you see when you look at an existing, mature product. Is that something you’d experienced at all, or have you managed to keep your code base really up to date?

Mina: I think that is something that I definitely have been experiencing. When I tried to learn how to do React on my own, I looked at various tutorials and things like that. And I noticed, or at least people have told me who have worked who have been working with me that some of the things that we do or kind of anti-pattern or not quite how things work now, because this code base is slightly, well mature us relative, but it’s a few years old. And so there are some ways that I guess are easier to do things than the way we’re doing them currently because this was written years ago. So it’s a little bit of a treadmill trying to keep up with current times and make sure I want to do things the best way, but also I don’t want to break an established code base because I want to play around with stuff.

Drew: Obviously, one of the things with React that people like you and I are coming to it, it can feel a bit jarring as this whole thing with JSX. Are you using JSX in your project?

Mina: We are. I am using JSX.

Drew: Have you made peace with that?

Mina: I fell like a little small piece of me dies every time I open one of those files. It still feels sacrilege to put my HTML in the JavaScript file. I know that’s kind of revolutionary and the whole point, but it just feels off to me that I’m writing my markup in a JavaScript file. I’ve made peace with it, but every time I do it, I’m just like, “…” Separation concerns, it is a thing. I’d like it back, please.

Drew: It’s a valid point, isn’t it? My background when I was starting to work more seriously with JavaScript, and this was probably when I was back at Yahoo, things were very much on the model of server rendered HTML pages and then taking a progressive enhancement approach, layering JavaScript on top to enhance the interface. And if the state of something in the interface needed to change, your code had to know about all the parts of the interface that it needed to update, which obviously leads you to a tightly coupled approach with these big monolithic views where the code you write needs to know about all the other code around it. And I guess that doesn’t really lend itself to a componentized approach which you would take when working with a pattern library or a design system, which is more to your area of particular expertise. I guess, React lends itself more to that approach, does it?

Mina: I think it does, especially with the being able to couple the very specific CSS to one JSX or one React component. And so that way it makes it much easier to separate or only take what you need for the library and leave the rest, whereas a pattern library or design system that attempts to do something more monolithic with just one big style CSS file or something like that, it does make it a lot difficult. You kind of have to take it all or nothing. So I do appreciate that React allows us to do more individualized, more componentized way of development, even if I still wish there was a way for me to do truly separate my presentation layer and my content layer from my interactivity layer. But maybe that’s just me being a little bit old school in that sense.

Drew: I definitely feel the pain there. The idea is that, come and correct me if I’m wrong, my understanding is that rather than separating the technologies, the CSS, and the JavaScript, and the HTML, it’s separating the functionality. So everything that is one component all exist together-

Mina: Yeah.

Drew: … which I guess is useful if that component then is no longer needed. You can just delete it, and it’s gone, and it doesn’t leave a footprint around your app. That’s not always the case with CSS though. How are you working with CSS with React? Have You looked at things like styled-components or anything like that?

Mina: No, we haven’t. I’ve heard of styled-components, but I’ve never quite really investigated them very fully to be perfectly honest. So the way that we’re working with CSS with React is we write Less, and we just have a Less file attached to each individual component that gets imported into that component. And then it gets bonded up via Webpack and served to the client.

Drew: Are you using a system like BEM or something to turn namespace?

Mina: Yeah. We’re using BEM for namespacing, although the adherence to it is kind of varied depending on who’s writing what. But we try to use a BEM namespacing pattern to make it a little bit clearer what the purpose of each individual class and component is.

Drew: And does that seem to be working successfully for you?

Mina: I think so. Occasionally it kind of has the same old problem of I sometimes don’t know how to name something. After a while daily things has always and will always be a difficult thing for master. So that’s the only issue I have with is I occasionally I have no idea what I should call a particular component.

Drew: Definitely. That’s a constant battle, isn’t it, how to out the name things?

Mina: Yeah.

Drew: I always end up when working on a new feature or something like that, you give a component and all the classes and everything the name that the feature has got at the moment. And then by the time you come to launch, it’s been renamed something else. So you have references to the old name in the code and the interface has the new name. And …

Mina: I try to always name things based on the function or the purpose of it versus things that are a little bit more ephemeral, because it’s less likely that the actual purpose of this component will change. I forgot to mention, but in addition to using BEM, I guess we use BEMITs if you’re familiar with that. It’s basically the ITCSS plus BEM, both of which were created by Harry Roberts. So I use Hungarian notation to denote whether or not something is a component, versus a layout object, versus like a larger pattern comprised of multiple components. And then from there we use the BEM convention to signify like the block element and all that.

Drew: And have you had to do much refactoring and deleting of components and things in your code base and had to deal with the issue of CSS getting left behind?

Mina: Yeah. So the non-React part of my job, of maintaining slack.com is that’s all just a bunch of Less files that are being compiled for CSS. And I guarantee you, there’s a lot of zombie code in there, because we definitely iterate above things a lot in the time I’ve been there. And we don’t always have time to go back and do the cleanup versus when we redesign a page or something. So it’s overdue for an audit, I’ll say that.

Drew: This is something that we’ve just been looking at in our React project, looking at how we approach CSS. At the moment, we have a few big, global CSS files for the whole of the app, and we do get this situation where our bundle size is just growing, and growing, and growing and never gets any smaller, even though things do get removed. So we’ve been looking at things like styled-components, Tailwind as well is another option that we’re really seriously considering. Have you looked at tailwind much?

Mina: I haven’t looked at it a lot. I’ve been curious about it, but again, I’ve never really had time to dig in to actually see if it’s something that I want to try to bring into our code base.

Drew: I was actually quite surprised, because like you, I’m a bit old school with how to do these things. I like nice separation of concerns. And I like to write my CSS in CSS, and of course the approach with Tailwind is you have all these class names, which feel a bit like inline styles that you’re applying. And if it feels dirty.

Mina: Yeah.

Drew: And I volunteered within the team, we each which took a technology to investigate if they’d be a good fit for our problems, and I volunteered to look at Tailwind because I was absolutely certain I was going to hate it.

Mina: No, no.

Drew: But it turns out I actually think it solves a lot of problems. I was quite impressed.

Mina: Yeah. I’ve sort of come around to a similar way of thinking, because I in the past would much prefer to have one class comprise all of the styles I needed for a particular component and not do a class per property, as I believe Tailwind does or languages like it do. For the similar reasons, it felt very much like, “Well, I’m just running inline CSS at this point. Why would I do this?” But as I’ve been developing more and more, inside of our Slack design system, I created a bunch of what I call utility classes that do things like add a bit of margin with a pattern. I’ve noticed that more and more, I’m using those classes in addition to the component classes. So I’m like, “Okay, well maybe I should revisit this whole to doing a CSS as a one declaration at a time.” I don’t know if I’d go that far, but it’s definitely worth considering.

Drew: Computing seems to flip flop in terms of trends between thin clients and fat clients solutions. We started with mainframes with terminals, and then the PC era with windows and office and all these sort of big applications. And they were all getting really slow, and than the web came along, and that was just a browser, and all the work was being done on the server. And it was all fast and snappy again. And now we’ve gone back to putting all that work back in the browser with everything being done with JavaScript, things like React and the JAMstack approach where we’re back to a sort of fat client. I sometimes worry that we’re asking too much of the browser. Is this a mistake? Are we asking too much of the browser trying to do all this stuff in React?

Mina: I want to say yes with the caveat of, again, my experience is very much contained to mostly static websites. I don’t do a lot of product development. So maybe in that realm, this makes more sense. But from my perspective, I feel like we’re a lot of the times using a hatchet when we just need a butter knife. I don’t know why we need put all this in the browser, put so much work and so much pressure on the client. I feel like we could do this much simpler. One of the things that always made me a little hesitant to use React, or I say hesitant, but what I mean when it made me viscerally angry and I actively opposed, was when I would go to a website and literally nothing would render because there was one error or something, Like, “Really? The entire page is broken because one function broke down?”

Mina: It just kind of annoyed me that a lot of times it was an all or nothing approach. One of the talks that I gave at AEA in the past and other places in the past was talking about how to include progressive enhancement and not just your development, but also of art direction and design of sites. And I would point out specifically examples of websites that didn’t do progressive enhancement or any kind of graceful degradation. It was like either you have the JavaScript running in the browser or you get absolutely nothing. And it would be like just a simple site that represent information about the history of web design, which was one of the sites actually talked about, the history of web design from like 1990 until now. It was a beautiful website with lots of timelines, animation of things. But it also could have been rendered statically with just a list. There were steps in between showing nothing and showing that beautifully enhanced experience that I think got lost because of the way we’ve been approaching modern web development now.

Drew: So would you say there are absolutely some categories of projects that suit a solution like React and some where it really shouldn’t be used and you should be using more traditional methods?

Mina: I think that if your site particularly is mostly static, it was just serving up information, I guess I don’t understand why you need a project like React to render something that doesn’t have a lot of interaction beyond just DOM manipulation. I guess I don’t see what benefit you get from that. Again, I may not be working on the appropriate projects. I may not just have seen or found that use case, but I’m having a hard time seeing if it’s just mostly static site, presenting content, not a lot interaction, not a lot of interaction beyond manipulated DOM and doing animations. I don’t see how having a React library helps you accomplish that goal.

Drew: It’s interesting because I’m not bad talking it because I haven’t actually used it, but I see a lot of Gatsby projects and Gatsby being a static site generator that uses a React front-end in it. And I see all the examples of the themes and things they have available are all content based sites, or blogs, and a recipe site, and a portfolio, and these sort of things. And there’s something I think actually that this isn’t necessarily the right fit for something like React. Why isn’t this being statically rendered and then progressively enhance?

Mina: Yeah.

Drew: It’s not software.

Mina: Yeah. I haven’t actually used Gatsby either. I’ve heard plenty of great things about it, but that’s probably one of the examples I would think of where I’m like, “Okay, I guess I’m just not seeing why that tool is necessary to do that particular job.” Again, I don’t know. Maybe it’s just because more people are comfortable writing in React when they are writing new something else, and it’s just providing a tool that meets people where they are. I’ve heard great things about static site generators that use React for people who have used them and love them, but it’s not a use case that I would have immediately been like, “Oh, that makes sense.”

Drew: It seems like there’s always been this battle between what we would call a website and what you might call a web app. And the chasm between the two seems to be getting wider, and wider, and wider, whereas a progressive enhancement approach tries to bridge the gap by taking something static and adding JavaScript and adding interactivity. It seems that things like React are ideally suited for software that you’re running in the browser. Would you agree with that?

Mina: I would definitely agree with that because it feels like it’s was built for that type of environment; it was built for running software. It was built by Facebook for Facebook. So it was built for a product. It was built for running whatever you call a web app in the browser and not necessarily for the type of work that, as I mentioned, I’m used to doing. So I think in those scenarios, it definitely makes a lot of sense to use it if you’re building a more complex, more sophisticated piece of software that’s meant to run inside of a browser. But if you’re building a marketing agency site or whatever, I guess I would still struggle to see why it will be necessary there.

Drew: So are we giving people permission to still build decent, statically rendered websites?

Mina: I would love to see more of that happen. I feel like that’s kind of gotten lost and it’s sort of lost its, if it ever was cool or whatever. I feel like we’ve lost that part of web development. It’s so funny: you and I both said that we’re kind of old school, and I laugh at that because I’ve actually been doing web development for, what, six years now? How am I old school? It hasn’t been that long for me. And yet somehow I’m part of the old guard who doesn’t like new and shiny things. I don’t get it.

Drew: So in fact React has actually existed for the whole time that you’ve been a web developer.

Mina: Maybe I just have an old soul. I don’t know.

Drew: I think that’s probably the case. I’ve not looked personally at, there are service side rendered approaches you can take with React apps. Have you experienced any of those?

Mina: I haven’t experienced any them. I briefly looked into them for the project I’m currently working on, because I feel like there’s parts of the operation that would work better on a server versus in the clients. But I think because of my limited knowledge and the fact that the code base is a little more complicated than I can understand, I wasn’t quite able to figure out how to make that part work. I would love to figure it out eventually, but I spent a day digging into it. I was like, “You know what? I’m not grokking this away I need to be. So I’m just going to back up and take a different route.”

Drew: Yeah. I think we’ve all been there.

Mina: Yeah. I went down a path. I was like, “Oh, this is dark and scary. Let’s reverse. Let’s reverse.”

Drew: Step away from the code.

Mina: Yes.

Drew: So you’ve been very diplomatic and polite about React so far. I sense that there’s some tension bubbling under the surface a bit. Come on. Tell us what you really feel.

Mina: I have been polite and diplomatic, mostly because the Reacts fan base can be a little mean sometimes, and I would rather not have them come for me. So please, React is great. It’s wonderful. Use it for what you want to use it for. I kid, but even that tweet that you mentioned at the beginning of this podcast where I think what you said is that I don’t hate it. I don’t love it, but I don’t hate it. Even that statement, I got people, there was no vitriol, but it was more they where ready to leap to the defense and say, “Well, I love it because X, Y, Z.” I’m like, “I didn’t say it was bad. I just said that I’m meh about the whole thing.” But apparently being meh is not okay. I have to love it.

Mina: So that’s why I probably have been a bit more diplomatic than I would ordinarily be, just because I don’t want people to think that I’m bad mouthing it, because I’m not. It has a place in more web development. It serves a function. It does its job well. People love it. It’s just not a tool that I’ve ever had or wanted to use until now.

Drew: Yeah. Things can get very tribal, can’t they, with people feeling like they have to take one side or another, and you’re either absolutely for something or absolutely against something? And I’m not sure it serves a good purpose, and I don’t think it really moves us forward as an industry and as a community to do that.

Mina: Yeah. It’s really odd. It’s fascinating to watch from just a sociological standpoint, but it’s often just really like weird to observe. It’s like I’m not allowed to just be, like I said, neutral about certain things. I have to have a strong opinion, which is I don’t think healthy. What’s the term, “Strong opinions, loosely held?” That’s kind of the way I go about things. I feel strongly about certain things, but it’s not like you can’t change my mind. Where I feel like some people, their identity gets wrapped up into certain aspects of it ,that if you are not for whatever they’ve chosen to identify with, it’s a personal slight versus just, I don’t care about this particular topic, or tool, or whatever.

Drew: Yes. I don’t know if it’s made worse by the fact that we all are sort of tending to specialize a lot more in particular parts of the stack. And I know there are people who are React developers. They would call themselves a React developer because that’s what they work in. And they wouldn’t necessarily write any vanilla Java script or wouldn’t use Vue or whatever. React is their world. So I guess it almost feels like an attack on their entire career to say, “I don’t like React.” Well, they’re really invested in making you like React or whatever the technology may be.

Mina: I will admit to being one of those people in the past. Actually, probably it was mostly about SASS, I believe. I was very much on the team of doing SASS as a preprocessor and all other preprocessors are trash. I don’t want to talk about them. I don’t want to deal with them. And I realized that was a very narrow way to look at things. Use the appropriate tool for the job. Whatever makes you more productive, that’s the right tool. It doesn’t really matter what it is.

Drew: Are there any technologies that we work with that don’t have that sort of tribal feel? Is there anything that people are just happy to use or not use? I can’t think of anything.

Mina: Wow. No one has opinions about markup, actually.

Drew: No.

Mina: I feel like no one has opinions about like actual HTML and just markup, just like, “It’s there.” They use it. But people have strong opinions about CSS and how it’s either terrible or wonderful, and the preprocessor wars that don’t really happen all that much anymore, and then of course, all of the tribalism within the various JavaScript libraries.

Drew: So you would say your journey so far with React is still just, “It’s a tool. It does its job?”

Mina: It went from a curiosity to active and visceral dislike because of how prevalent it was and how I unnecessary I thought that that prevalence was to meh. I’m now with meh, which again does not mean I hate it. It just means …

Drew: I think that’s a good place to be. I think we’re probably all sort of stronger as technologists if we understand the value of a particular technology for its purpose. We can evaluate what is good for what circumstance and pick the right tool for the job.

Mina: Yeah. And that’s kind of where I’ve arrived at this point in my career where I don’t get really invested in any particular language, or technology, or whatever, because it’s like, “Just whatever tool is most appropriate for what you’re trying to do, then use that.” I’ve learned that there’s a place for everything; there’s a time and a place to do everything. And up until recently, there was no real time or place for me to use this React librarian, and now there is.

Drew: I think that’s a good place to be. So I’ve been learning all about React lately as you have in the day job. Is there anything else that you’ve been learning about lately?

Mina: I’ve actually learned ironically, which is I think another language that has originated at Facebook, I’ve been doing a lot of Hack development, mostly because that’s what I use at Slack, at my day job. Learning Hack paved the way for me to get more comfortable using React because they follow very similar patterns, except one is server side and one’s not. So that, along with just in general, I’ve been learning more about the back-end and how that works for various different reasons. And I’ve been stretching myself for the past couple years and getting more and more outside of my comfortable zone. Design systems, libraries, that’s very much my world, and I feel very good and comfortable in that world. But I’m stepping outside of it and doing a lot more server side logic, and API development, and data modeling, and all of that. I’ve been doing a lot on that for the past year as well.

Drew: I find that the more I understand about the whole stack about back-end stuff in front-end stuff, each one helps my knowledge of the other. I find I write better front-end code by having written back-end code and understanding-

Mina: Yeah. I think I feel the same way. Now that I have a better idea of, like we said, the whole stack of how we get from the data to the end client. I find that I’m thinking about the entire pipeline no matter what part I’m actually working in. I’m thinking about what’s the best way to structure this API so that when I get to the template, I don’t have to do so much manipulating of the data that I receive on that end of it. It’s definitely made me overall a better engineer, I feel like it

Drew: If you, dear listener, would like to hear more from Mina, you can follow her on Twitter where she’s @MinaMarkham and find her personal site at mina.codes. Thanks for joining us today, Mina. Do you have any parting words?

Mina: Have a smashing night?

Drew: Great.

(il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

source http://www.scpie.org/smashing-podcast-episode-18-with-mina-markham-how-can-i-learn-react/ source https://scpie1.blogspot.com/2020/06/smashing-podcast-episode-18-with-mina.html

[t-baba]

Create a Contact Form in PHP

No matter what type of website you own or manage, you probably need a contact form. The contact form can help your visitors request a quote, ask for information, or share any tips or problems they're facing while using your website.

In this tutorial, our focus will be on creating a fully functional contact form in PHP from beginning to end. We will begin with the markup of all the fields that we need to add and the basic styling of the contact form. After that, we will move on to the PHP code to implement its functionality.

Of course, the easiest way to create a contact form is to download a professional contact form script from CodeCanyon.

PHP

18 Best Contact Form PHP Scripts for 2020

Monty Shokeen

But if you want to learn about how a contact form is created, read on! It might just be easier than you think.

Markup of Our HTML Contact Form

The first step towards creating our own contact form is to code the markup. We will start doing that once we have a list of all the elements that we want inside our form. We'll need an input field for the name of the person who is contacting us, and we'll need a field for their email address so that we can send a reply back to them if the need arises. We'll also need an input field for the reason people are contacting you and a textarea where users can type their message.

If the website you are managing is very popular, you'll be getting a lot of emails through the contact form. To make sure that the right people get to read those emails and respond quickly, you need a couple more fields. For instance, you could add a field that can determine which department the visitor wants to contact like marketing, support, or billing. This information can later be used to route the email appropriately. Ultimately, that might help you reply more quickly and sort the emails more efficiently.

How many fields you add to the contact form depends on the type of website you run, but make sure you don't overdo it. Forcing visitors to fill out too many details might discourage them from contacting you altogether.

Let's write the HTML code to add all the fields I just mentioned into our contact form.

<form action="contact.php" method="post"> <div class="elem-group"> <label for="name">Your Name</label> <input type="text" id="name" name="visitor_name" placeholder="John Doe" pattern=[A-Z\sa-z]{3,20} required> </div> <div class="elem-group"> <label for="email">Your E-mail</label> <input type="email" id="email" name="visitor_email" placeholder="john.doe@email.com" required> </div> <div class="elem-group"> <label for="department-selection">Choose Concerned Department</label> <select id="department-selection" name="concerned_department" required> <option value="">Select a Department</option> <option value="billing">Billing</option> <option value="marketing">Marketing</option> <option value="technical support">Technical Support</option> </select> </div> <div class="elem-group"> <label for="title">Reason For Contacting Us</label> <input type="text" id="title" name="email_title" required placeholder="Unable to Reset my Password" pattern=[A-Za-z0-9\s]{8,60}> </div> <div class="elem-group"> <label for="message">Write your message</label> <textarea id="message" name="visitor_message" placeholder="Say whatever you want." required></textarea> </div> <button type="submit">Send Message</button> </form>

Before proceeding any further, I would like to quickly summarize the meaning of some important attributes in the above markup. The action attribute in the form determines where the form data needs to be sent. If you don't have an action attribute, the data is sent back to the same URL. Here we've used contact.php, so the form data will be sent to that script.

The name attribute for different input elements in the form is used to access the element values on the server side. For example, in the above form, you can get the name of the visitor contacting you using $_POST['visitor_name'] in contact.php.

We use the placeholder attribute to give users a basic idea of the expected input for each field in the form. The required attribute ensures that no important field is left blank before the user hits the submit button on the form. 

The pattern attribute is used to enforce some rules on the kinds of values that can go inside certain fields. In our case, we only allow users to use letters and the space character in the names they submit. We also limit the total number of acceptable characters to anything from 3 to 20 inclusive. The pattern that you use will depend on the type of input that you want from users.

The following CodePen demo shows us what our contact form looks like with the above markup and a little bit of CSS.

Making Our HTML Contact Form Functional Using PHP

Right now, our form doesn't do anything useful. Visitors can fill it out and hit the send message button, but we won't receive anything because there is no server-side code to handle the information provided by the form. In this section, we'll make our contact form functional using PHP.

Begin by creating a contact.php file and putting the following code inside it.

<?php if($_POST) { $visitor_name = ""; $visitor_email = ""; $email_title = ""; $concerned_department = ""; $visitor_message = ""; $email_body = "<div>"; if(isset($_POST['visitor_name'])) { $visitor_name = filter_var($_POST['visitor_name'], FILTER_SANITIZE_STRING); $email_body .= "<div> <label><b>Visitor Name:</b></label>��<span>".$visitor_name."</span> </div>"; } if(isset($_POST['visitor_email'])) { $visitor_email = str_replace(array("\r", "\n", "%0a", "%0d"), '', $_POST['visitor_email']); $visitor_email = filter_var($visitor_email, FILTER_VALIDATE_EMAIL); $email_body .= "<div> <label><b>Visitor Email:</b></label> <span>".$visitor_email."</span> </div>"; } if(isset($_POST['email_title'])) { $email_title = filter_var($_POST['email_title'], FILTER_SANITIZE_STRING); $email_body .= "<div> <label><b>Reason For Contacting Us:</b></label> <span>".$email_title."</span> </div>"; } if(isset($_POST['concerned_department'])) { $concerned_department = filter_var($_POST['concerned_department'], FILTER_SANITIZE_STRING); $email_body .= "<div> <label><b>Concerned Department:</b></label> <span>".$concerned_department."</span> </div>"; } if(isset($_POST['visitor_message'])) { $visitor_message = htmlspecialchars($_POST['visitor_message']); $email_body .= "<div> <label><b>Visitor Message:</b></label> <div>".$visitor_message."</div> </div>"; } if($concerned_department == "billing") { $recipient = "billing@domain.com"; } else if($concerned_department == "marketing") { $recipient = "marketing@domain.com"; } else if($concerned_department == "technical support") { $recipient = "tech.support@domain.com"; } else { $recipient = "contact@domain.com"; } $email_body .= "</div>"; $headers = 'MIME-Version: 1.0' . "\r\n" .'Content-type: text/html; charset=utf-8' . "\r\n" .'From: ' . $visitor_email . "\r\n"; if(mail($recipient, $email_title, $email_body, $headers)) { echo "<p>Thank you for contacting us, $visitor_name. You will get a reply within 24 hours.</p>"; } else { echo '<p>We are sorry but the email did not go through.</p>'; } } else { echo '<p>Something went wrong</p>'; } ?>

We have already done some client-side validation of user input. However, it's always safer to do server-side validation as well. We use the filter_var() function to sanitize the name provided by the user. In a similar fashion, we also sanitize the value of $email_title and $concerned_department. You can use the filter_var()function to validate or sanitize all types of user input. We also use the htmlspecialchars() function to encode all the special HTML characters in the visitor message sent to us.

The value of $recipient is based on the value of the variable $concerned_department. This way, we make sure that only people who are actually supposed to look into the matter receive the email.

Also, we've used the $email_body variable to format the email body which will be the main content of the email. As we are sending an email in the HTML format, we've used HTML to format the email body content.

Finally, we use the mail() function to send an email which includes the information the visitor wanted us to know. Upon successful delivery of the email, we let the visitors know that we have received their email and that they will be contacted soon.

Security is paramount when you are dealing with user data or input. Whether you should validate or sanitize the user input depends on what the input is and how you want to use it. Validation simply checks if the user input follows a certain set of rules. For example, validation could check that the name of a person does not contain any numbers. Sanitization is used to remove any offending characters that pose a security risk. For example, a malicious user trying to contact you through the form might add a script tag in the textarea to get you to download a harmful script. This is particularly worrisome when your website has public forums accessible by everyone.

However, you have to be very careful when getting rid of unwanted characters in user input. For example, you might decide to use filter_var($user_input, FILTER_SANITIZE_STRING); on some input to strip all tags and encode special characters. However, this flag also strips harmless character input by legitimate users. Here is an example:

<?php $string = 'One of your posts about inequalities mentioned that when x < y and y < z then x < z.'; // Output: One of your posts about inequalities mentioned that when x echo filter_var($string, FILTER_SANITIZE_STRING); // Output: One of your posts about inequalities mentioned that when x < y and y < z then x < z. echo htmlspecialchars($string); ?>

If your website has a lot of maths-related topics, it will be relatively common for users to write < or > in contact forms or forum posts. Using the FILTER_SANITIZE_STRING flag with the filter_var() function will strip necessary information from the message in this case.

The point I am trying to make is that even though you should always validate or sanitize user data, make sure that you are not stripping away crucial information in the process.

Final Thoughts

Creating a basic contact form in PHP is pretty simple. You begin by writing the HTML needed to create input elements for information like the user's name, email address, phone number, etc. The next step is writing CSS to make sure the contact form blends in perfectly with the rest of the website. The final step involves writing the PHP code that will take the information from the contact form and securely mail it to you.

The aim is to make sure that different form elements are laid out in a way that does not confuse people and the user input is sanitized and validated before you mail it to concerned parties. If all this is new to you or if you don't want to spend a lot of time creating a professional-looking contact form, you should definitely check out these top-rated contact form PHP scripts.

If you have any questions, feel free to let me know in the comments. My next tutorial will show you how to implement your own CAPTCHA to help keep contact form spam in check. 

If you're interested in professional-quality PHP form scripts that you can start using on your site today, check out some of our other posts.

20 Best PHP Email Forms

PHP email forms have many uses. While some may need a basic contact form, some need forms to collect more data. For example, you might be creating a website...

Esther Vaati

29 Jun 2020

PHP

18 Best Contact Form PHP Scripts for 2020

Are you looking for an easy-to-use contact form PHP script? Contact forms are a must-have for every website, and with 14 premium scripts from CodeCanyon and...

Monty Shokeen

29 Jul 2020

PHP

19 PHP Login and Registration Forms to Download

By downloading a PHP login and registration script, you can add a registration form to your website that will be secure and look good.

Daniel Stern

16 Apr 2020

PHP

by Monty Shokeen via Envato Tuts+ Code https://ift.tt/330edVg