Posted on

How to Think Like a Front-End Developer

This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.”

The moment I fell in love with front-end development was when I discovered the style.css file in WordPress themes. That’s where all the magic was (is!) to me. I could (can!) change a handful of lines in there and totally change the look and feel of a website. It’s an incredible game to play.

Back when I was cowboy-coding over FTP. Although I definitely wasn’t using CSS grid!

By fiddling with HTML and CSS, I can change the way you feel about a bit of writing. I can make you feel more comfortable about buying tickets to an event. I can increase the chances you share something with your friends.

That was well before anybody paid me money to be a front-end developer, but even then I felt the intoxicating mix of stimuli that the job offers. Front-end development is this expressive art form, but often constrained by things like the need to directly communicate messaging and accomplish business goals.

Front-end development is at the intersection of art and logic. A cross of business and expression. Both left and right brain. A cocktail of design and nerdery.

I love it.

Looking back at the courses I chose from middle school through college, I bounced back and forth between computer-focused classes and art-focused classes, so I suppose it’s no surprise I found a way to do both as a career.

The term “Front-End Developer” is fairly well-defined and understood. For one, it’s a job title. I’ll bet some of you literally have business cards that say it on there, or some variation like: “Front-End Designer,” “UX Developer,” or “UI Engineer.” The debate around what those mean isn’t particularly interesting to me. I find that the roles are so varied from job-to-job and company-to-company that job titles will never be enough to describe things. Getting this job is more about demonstrating you know what you’re doing more than anything else¹.

Chris Coyier
Front-End Developer

The title variations are just nuance. The bigger picture is that as long as the job is building websites, front-enders are focused on the browser. Quite literally:

  • front-end = browsers
  • back-end = servers

Even as the job has changed over the decades, that distinction still largely holds.

As “browser people,” there are certain truths that come along for the ride. One is that there is a whole landscape of different browsers and, despite the best efforts of standards bodies, they still behave somewhat differently. Just today, as I write, I dealt with a bug where a date string I had from an API was in a format such that Firefox threw an error when I tried to use the .toISOString() JavaScript API on it, but was fine in Chrome. That’s just life as a front-end developer. That’s the job.

Even across that landscape of browsers, just on desktop computers, there is variance in how users use that browser. How big do they have the window open? Do they have dark mode activated on their operating system? How’s the color gamut on that monitor? What is the pixel density? How’s the bandwidth situation? Do they use a keyboard and mouse? One or the other? Neither? All those same questions apply to mobile devices too, where there is an equally if not more complicated browser landscape. And just wait until you take a hard look at HTML emails.

That’s a lot of unknowns, and the answers to developing for that unknown landscape is firmly in the hands of front-end developers.

Into the unknoooooowwwn. – Elsa

The most important aspect of the job? The people that use these browsers. That’s why we’re building things at all. These are the people I’m trying to impress with my mad CSS skills. These are the people I’m trying to get to buy my widget. Who all my business charts hinge upon. Who’s reaction can sway my emotions like yarn in the breeze. These users, who we put on a pedestal for good reason, have a much wider landscape than the browsers do. They speak different languages. They want different things. They are trying to solve different problems. They have different physical abilities. They have different levels of urgency. Again, helping them is firmly in the hands of front-end developers. There is very little in between the characters we type into our text editors and the users for whom we wish to serve.

Being a front-end developer puts us on the front lines between the thing we’re building and the people we’re building it for, and that’s a place some of us really enjoy being.

That’s some weighty stuff, isn’t it? I haven’t even mentioned React yet.

The “we care about the users” thing might feel a little precious. I’d think in a high functioning company, everyone would care about the users, from the CEO on down. It’s different, though. When we code a <button>, we’re quite literally putting a button into a browser window that users directly interact with. When we adjust a color, we’re adjusting exactly what our sighted users see when they see our work.

That’s not far off from a ceramic artist pulling a handle out of clay for a coffee cup. It’s applying craftsmanship to a digital experience. While a back-end developer might care deeply about the users of a site, they are, as Monica Dinculescu once told me in a conversation about this, “outsourcing that responsibility.”

We established that front-end developers are browser people. The job is making things work well in browsers. So we need to understand the languages browsers speak, namely: HTML, CSS, and JavaScript². And that’s not just me being some old school fundamentalist; it’s through a few decades of everyday front-end development work that knowing those base languages is vital to us doing a good job. Even when we don’t work directly with them (HTML might come from a template in another language, CSS might be produced from a preprocessor, JavaScript might be mostly written in the parlance of a framework), what goes the browser is ultimately HTML, CSS, and JavaScript, so that’s where debugging largely takes place and the ability of the browser is put to work.

CSS will always be my favorite and HTML feels like it needs the most love — but JavaScript is the one we really need to examine The last decade has seen JavaScript blossom from a language used for a handful of interactive effects to the predominant language used across the entire stack of web design and development. It’s possible to work on websites and writing nothing but JavaScript. A real sea change.

JavaScript is all-powerful in the browser. In a sense, it supersedes HTML and CSS, as there is nothing either of those languages can do that JavaScript cannot. HTML is parsed by the browser and turned into the DOM, which JavaScript can also entirely create and manipulate. CSS has its own model, the CSSOM, that applies styles to elements in the DOM, which JavaScript can also create and manipulate.

This isn’t quite fair though. HTML is the very first file that browsers parse before they do the rest of the work needed to build the site. That firstness is unique to HTML and a vital part of making websites fast.

In fact, if the HTML was the only file to come across the network, that should be enough to deliver the basic information and functionality of a site.

That philosophy is called Progressive Enhancement. I’m a fan, myself, but I don’t always adhere to it perfectly. For example, a <form> can be entirely functional in HTML, when it’s action attribute points to a URL where the form can be processed. Progressive Enhancement would have us build it that way. Then, when JavaScript executes, it takes over the submission and has the form submit via Ajax instead, which might be a nicer experience as the page won’t have to refresh. I like that. Taken further, any <button> outside a form is entirely useless without JavaScript, so in the spirit of Progressive Enhancement, I should wait until JavaScript executes to even put that button on the page at all (or at least reveal it). That’s the kind of thing where even those of us with the best intentions might not always toe the line perfectly. Just put the button in, Sam. Nobody is gonna die.

JavaScript’s all-powerfulness makes it an appealing target for those of us doing work on the web — particularly as JavaScript as a language has evolved to become even more powerful and ergonomic, and the frameworks that are built in JavaScript become even more-so. Back in 2015, it was already so clear that JavaScript was experiencing incredible growth in usage, Matt Mullenweg, co-founder of WordPress, gave the developer world homework: “Learn JavaScript Deeply”³. He couldn’t have been more right. Half a decade later, JavaScript has done a good job of taking over front-end development. Particularly if you look at front-end development jobs.

While the web almanac might show us that only 5% of the top-zillion sites use React compared to 85% including jQuery, those numbers are nearly flipped when looking around at front-end development job requirements.

I’m sure there are fancy economic reasons for all that, but jobs are as important and personal as it gets for people, so it very much matters.

So we’re browser people in a sea of JavaScript building things for people. If we take a look at the job at a practical day-to-day tasks level, it’s a bit like this:

  • Translate designs into code
  • Think in terms of responsive design, allowing us to design and build across the landscape of devices
  • Build systemically. Construct components and patterns, not one-offs.
  • Apply semantics to content
  • Consider accessibility
  • Worry about the performance of the site. Optimize everything. Reduce, reuse, recycle.

Just that first bullet point feels like a college degree to me. Taken together, all of those points certainly do.

This whole list is a bit abstract though, so let’s apply it to something we can look at. What if this website was our current project?

Our brains and fingers go wild!

  • Let’s build the layout with CSS grid. 
  • What fonts are those? Do we need to load them in their entirety or can we subset them? What happens as they load in? This layout feels like it will really suffer from font-shifting jank. 
  • There are some repeated patterns here. We should probably make a card design pattern. Every website needs a good card pattern. 
  • That’s a gorgeous color scheme. Are the colors mathematically related? Should we make variables to represent them individually or can we just alter a single hue as needed? Are we going to use custom properties in our CSS? Colors are just colors though, we might not need the cascading power of them just for this. Should we just use Sass variables? Are we going to use a CSS preprocessor at all?
  • The source order is tricky here. We need to order things so that they make sense for a screen reader user. We should have a meeting about what the expected order of content should be, even if we’re visually moving things around a bit with CSS grid.
  • The photographs here are beautifully shot. But some of them match the background color of the site… can we get away with alpha-transparent PNGs here? Those are always so big. Can any next-gen formats help us? Or should we try to match the background of a JPG with the background of the site seamlessly. Who’s writing the alt text for these?
  • There are some icons in use here. Inline SVG, right? Certainly SVG of some kind, not icon fonts, right? Should we build a whole icon system? I guess it depends on how we’re gonna be building this thing more broadly. Do we have a build system at all?
  • What’s the whole front-end plan here? Can I code this thing in vanilla HTML, CSS, and JavaScript? Well, I know I can, but what are the team expectations? Client expectations? Does it need to be a React thing because it’s part of some ecosystem of stuff that is already React? Or Vue or Svelte or whatever? Is there a CMS involved?
  • I’m glad the designer thought of not just the “desktop” and “mobile” sizes but also tackled an in-between size. Those are always awkward. There is no interactivity information here though. What should we do when that search field is focused? What gets revealed when that hamburger is tapped? Are we doing page-level transitions here?

I could go on and on. That’s how front-end developers think, at least in my experience and in talking with my peers.

A lot of those things have been our jobs forever though. We’ve been asking and answering these questions on every website we’ve built for as long as we’ve been doing it. There are different challenges on each site, which is great and keeps this job fun, but there is a lot of repetition too.

Allow me to get around to the title of this article. 

While we’ve been doing a lot of this stuff for ages, there is a whole pile of new stuff we’re starting to be expected to do, particularly if we’re talking about building the site with a modern JavaScript framework. All the modern frameworks, as much as they like to disagree about things, agree about one big thing: everything is a component. You nest and piece together components as needed. Even native JavaScript moves toward its own model of Web Components.

I like it, this idea of components. It allows you and your team to build the abstractions that make the most sense to you and what you are building.

Your Card component does all the stuff your card needs to do. Your Form component does forms how your website needs to do forms. But it’s a new concept to old developers like me. Components in JavaScript have taken hold in a way that components on the server-side never did. I’ve worked on many a WordPress website where the best I did was break templates into somewhat arbitrary include() statements. I’ve worked on Ruby on Rails sites with partials that take a handful of local variables. Those are useful for building re-usable parts, but they are a far cry from the robust component models that JavaScript frameworks offer us today.

All this custom component creation makes me a site-level architect in a way that I didn’t use to be. Here’s an example. Of course I have a Button component. Of course I have an Icon component. I’ll use them in my Card component. My Card component lives in a Grid component that lays them out and paginates them. The whole page is actually built from components. The Header component has a SearchBar component and a UserMenu component. The Sidebar component has a Navigation component and an Ad component. The whole page is just a special combination of components, which is probably based on the URL, assuming I’m all-in on building our front-end with JavaScript. So now I’m dealing with URLs myself, and I’m essentially the architect of the entire site. [Sweats profusely]

Like I told ya, a whole pile of new responsibility.

Components that are in charge of displaying content are almost certainly not hard-coded with data in them. They are built to be templates. They are built to accept data and construct themselves based on that data. In the olden days, when we were doing this kind of templating, the data has probably already arrived on the page we’re working on. In a JavaScript-powered app, it’s more likely that that data is fetched by JavaScript. Perhaps I’ll fetch it when the component renders. In a stack I’m working with right now, the front end is in React, the API is in GraphQL and we use Apollo Client to work with data. We use a special “hook” in the React components to run the queries to fetch the data we need, and another special hook when we need to change that data. Guess who does that work? Is it some other kind of developer that specializes in this data layer work? No, it’s become the domain of the front-end developer.

Speaking of data, there is all this other data that a website often has to deal with that doesn’t come from a database or API. It’s data that is really only relevant to the website at this moment in time.

  • Which tab is active right now?
  • Is this modal dialog open or closed?
  • Which bar of this accordion is expanded?
  • Is this message bar in an error state or warning state?
  • How many pages are you paginated in?
  • How far is the user scrolled down the page?

Front-end developers have been dealing with that kind of state for a long time, but it’s exactly this kind of state that has gotten us into trouble before. A modal dialog can be open with a simple modifier class like <div class="modal is-open"> and toggling that class is easy enough with .classList.toggle(".is-open"); But that’s a purely visual treatment. How does anything else on the page know if that modal is open or not? Does it ask the DOM? In a lot of jQuery-style apps of yore, yes, it would. In a sense, the DOM became the “source of truth” for our websites. There were all sorts of problems that stemmed from this architecture, ranging from a simple naming change destroying functionality in weirdly insidious ways, to hard-to-reason-about application logic making bug fixing a difficult proposition.

Front-end developers collectively thought: what if we dealt with state in a more considered way? State management, as a concept, became a thing. JavaScript frameworks themselves built the concept right in, and third-party libraries have paved and continue to pave the way. This is another example of expanding responsibility. Who architects state management? Who enforces it and implements it? It’s not some other role, it’s front-end developers.

There is expanding responsibility in the checklist of things to do, but there is also work to be done in piecing it all together. How much of this state can be handled at the individual component level and how much needs to be higher level? How much of this data can be gotten at the individual component level and how much should be percolated from above? Design itself comes into play. How much of the styling of this component should be scoped to itself, and how much should come from more global styles?

It’s no wonder that design systems have taken off in recent years. We’re building components anyway, so thinking of them systemically is a natural fit.

Let’s look at our design again:

A bunch of new thoughts can begin!

  • Assuming we’re using a JavaScript framework, which one? Why? 
  • Can we statically render this site, even if we’re building with a JavaScript framework? Or server-side render it? 
  • Where are those recipes coming from? Can we get a GraphQL API going so we can ask for whatever we need, whenever we need it?
  • Maybe we should pick a CMS that has an API that will facilitate the kind of front-end building we want to do. Perhaps a headless CMS?
  • What are we doing for routing? Is the framework we chose opinionated or unopinionated about stuff like this?

  • What are the components we need? A Card, Icon, SearchForm, SiteMenu, Img… can we scaffold these out? Should we start with some kind of design framework on top of the base framework?
  • What’s the client state we might need? Current search term, current tab, hamburger open or not, at least.
  • Is there a login system for this site or not? Are logged in users shown anything different? 
  • Is there are third-party componentry we can leverage here?
  • Maybe we can find one of those fancy image components that does blur-up loading and lazy loading and all that.

Those are all things that are in the domain of front-end developers these days, on top of everything that we already need to do. Executing the design, semantics, accessibility, performance… that’s all still there. You still need to be proficient in HTML, CSS, JavaScript, and how the browser works. Being a front-end developer requires a haystack of skills that grows and grows. It’s the natural outcome of the web getting bigger. More people use the web and internet access grows. The economy around the web grows. The capability of browsers grows. The expectations of what is possible on the web grows. There isn’t a lot shrinking going on around here.

We’ve already reached the point where most front-end developers don’t know the whole haystack of responsibilities. There are lots of developers still doing well for themselves being rather design-focused and excelling at creative and well-implemented HTML and CSS, even as job posts looking for that dwindle.

There are systems-focused developers and even entire agencies that specialize in helping other companies build and implement design systems. There are data-focused developers that feel most at home making the data flow throughout a website and getting hot and heavy with business logic. While all of those people might have “front-end developer” on their business card, their responsibilities and even expectations of their work might be quite different. It’s all good, we’ll find ways to talk about all this in time.

In fact, how we talk about building websites has changed a lot in the last decade. Some of my early introduction to web development was through WordPress. WordPress needs a web server to run, is written in PHP, and stores it’s data in a MySQL database. As much as WordPress has evolved, all that is still exactly the same. We talk about that “stack” with an acronym: LAMP, or Linux, Apache, MySQL and PHP. Note that literally everything in the entire stack consists of back-end technologies. As a front-end developer, nothing about LAMP is relevant to me.

But other stacks have come along since then. A popular stack was MEAN (Mongo, Express, Angular and Node). Notice how we’re starting to inch our way toward more front-end technologies? Angular is a JavaScript framework, so as this stack gained popularity, so too did talking about the front-end as an important part of the stack. Node and Express are both JavaScript as well, albeit the server-side variant.

The existence of Node is a huge part of this story. Node isn’t JavaScript-like, it’s quite literally JavaScript. It makes a front-end developer already skilled in JavaScript able to do server-side work without too much of a stretch.

“Serverless” is a much more modern tech buzzword, and what it’s largely talking about is running small bits of code on cloud servers. Most often, those small bits of code are in Node, and written by JavaScript developers. These days, a JavaScript-focused front-end developer might be writing their own serverless functions and essentially being their own back-end developer. They’ll think of themselves as full-stack developers, and they’ll be right.

Shawn Wang coined a term for a new stack this year: STAR or Design System, TypeScript, Apollo, and React. This is incredible to me, not just because I kind of like that stack, but because it’s a way of talking about the stack powering a website that is entirely front-end technologies. Quite a shift.

I apologize if I’ve made you feel a little anxious reading this. If you feel like you’re behind in understanding all this stuff, you aren’t alone.

In fact, I don’t think I’ve talked to a single developer who told me they felt entirely comfortable with the entire world of building websites. Everybody has weak spots or entire areas where they just don’t know the first dang thing. You not only can specialize, but specializing is a pretty good idea, and I think you will end up specializing to some degree whether you plan to or not. If you have the good fortune to plan, pick things that you like. You’ll do just fine.

The only constant in life is change.

– Heraclitus     – Motivational Poster         – Chris Coyier

¹ I’m a white dude, so that helps a bunch, too. ↩️
² Browsers speak a bunch more languages. HTTP, SVG, PNG… The more you know the more you can put to work! ↩️
³ It’s an interesting bit of irony that WordPress websites generally aren’t built with client-side JavaScript components. ↩️

The post How to Think Like a Front-End Developer appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

Posted on

Import Projects From Git Into Eclipse

Import Projects From Git Into Eclipse

As a VCS (Version Control System) I’m using git in all my projects. And not only for software or firmware projects: I’m using it for hardware design (KiCAD, FreeCAD, …) or for documentation (LaTeX, …) too.

The nice thing with the Eclipse IDE is that it supports nice git integration, making importing projects from git repositories easy.

Posted on

WordPress 5.6 Release Team Pulls the Plug on Block-Based Widgets

Widgets admin screen from the Gutenberg 9.1.1 WordPress plugin.
Current block-based widgets admin screen design.

I was wrong. I assured our readers that “the block-based widget system will be ready for prime time when WordPress 5.6 lands” in my previous post on the new feature’s readiness. I also said that was on the condition of not trying to make it work with the customizer — that experience was still broken. However, the 5.6 team pulled the plug on block-based widgets for the second time this year.

One week ago, WordPress 5.6 release lead Josepha Haden seemed to agree that it would be ready. However, things can change quickly in a development cycle, and tough decisions have to be made with beta release deadlines.

This is not the first feature the team has punted to a future release. Two weeks ago, they dropped block-based nav menus from the 5.6 feature list. Both features were originally planned for WordPress 5.5.

A new Widgets admin screen has been under development since January 2019, which was not long after the initial launch of the block editor in WordPress 5.0. For now, the block-based widgets feature has been punted to WordPress 5.7. It has also been given the “early” tag, which means it should go into core WordPress soon after the 5.7 release cycle begins. This will give it more time to mature and more people an opportunity to test it.

Helen Hou-Sandì, the core tech lead for 5.6, provided a historical account of the decision and why it was not ready for inclusion in the new ticket:

My question for features that affect the front-end is “can I try out this new thing without the penalty of messing up my site?” — that is, user trust. At this current moment, given that widget areas are not displayed anything like what you see on your site without themes really putting effort into it and that you have to save your changes live without revisions to get an actual contextual view, widget area blocks do not allow you to try this new feature without penalizing you for experimenting.

She went on to say that the current experience is subpar at the moment. Problems related to the customizer experience, which I covered in detail over a month ago, were also mentioned.

“So, when we come back to this again, let’s keep sight of what it means to keep users feeling secure that they can get their site looking the way they want with WordPress, and not like they are having to work around what we’ve given them,” said Hou-Sandì.

This is a hopeful outlook despite the tough decision. Sometimes, these types of calls need to be made for the good of the project in the long term. Pushing back a feature to a future version for a better user experience can be better than launching early with a subpar experience.

“The good part of this is that now widgets can continue to be ‘re-imagined’ for 5.7, and get even more enhancements,” said lead WordPress developer Andrew Ozz in the ticket. “Not sure how many people have tested this for a bit longer but having blocks in the widgets areas (a.k.a. sidebars) opens up many new possibilities and makes a lot of the old, limited widgets obsolete. The ‘widget areas’ become something like ‘specialized posts with more dynamic content,’ letting users (and designers) do a lot of stuff that was either hard or impossible with the old widgets.”

After the letdown of seeing one of my most anticipated features of 5.6 being dropped, it is encouraging to see the positive outlook from community leaders on the project.

“You know, I was really hopeful for it too, and that last-minute call was one I labored over,” said Haden. “When I last looked, it did seem close to ready, but then more focused testing was done and there were some interactions that are a little rough for users. I’m grateful for that because the time to discover painful user experiences is before launch rather than after!”

Despite dropping its second major feature, WordPress 5.6 still has some big highlights that will be shipping in less than two months. The new Twenty Twenty-One theme looks to be a breath of fresh air and will explore block-related features not seen in previous default themes. Haden also pointed out auto-updates for major releases, application passwords support for the REST API, and accessibility improvements as features to look forward to.

WordPress 5.6 Beta 1 is expected to ship today.

Adding New Features To an Old Project

At times, it feels like the Gutenberg project has bitten off more than it can chew. Many of the big feature plans continually miss projections. Between full-site editing, global styles, widgets, nav menus, and much more, it is tough to get hyper-focused on one feature and have it ready to ship. On the other hand, too much focus one way can be to the detriment to other features in the long run. All of these pieces must eventually come together to create a more cohesive whole.

WordPress is also 17 years old. Any new feature could affect legacy features or code. The goal is for block-based widgets is to transition an existing feature to work within a new system without breaking millions of websites in the process. Twenty-one months of work on a single feature shows that it is not an easy problem to solve.

“You are so right about complex engineering problems!” said Haden. “We are now at a point in the history of the project where connecting all of the pieces can have us facing unforeseen complications.”

The project also needs to think about how it can address some of the issues it has faced with not quite getting major features to completion. Is the team stretched too thin to focus on all the parts? Are there areas we can improve to push features forward?

“There will be a retrospective where we can identify what parts of our process can be improved in the future, but I also feel like setting stretch goals is good for any software project,” said Haden. “Many contributors have a sense of urgency around bringing the power of blocks to more spaces in WordPress, which I share, but when it’s time to ship, we have to balance that with our deep commitment to usability.”

One problem that has become increasingly obvious is that front-end editing has become tougher over the years. Currently, widgets and nav menus can be edited in two places in WordPress with wildly different interfaces. Full-site editing stands to add an entirely new interface to the mix.

“I think one of the problems that we’re trying to solve with Gutenberg has always been a more consistent experience for editing elements across the WordPress interface,” said Haden. “No user should have to learn five different workflows to make sure their page looks the way they imagined it when it’s published.”

In the meantime, which may be numbered in years, end-users will likely have these multiple interfaces to deal with — overlap while new features are being developed. This may simply be a necessary growing pain of an aging project, one that is trying to lead the pack of hungry competitors in the CMS space.

“There’s a lot of interest in reducing the number of workflows, and I’m hopeful that we can consolidate down to just one beautiful, intuitive interface,” said Haden.

Posted on

Convert C++ Code to C

This is my Code C++ for my assignment. Please help me to convert it to C code. Thank you!

#include<iostream>
using namespace std;
#define N 10

int main()
{
    int array[N],p,q;
    for(int i=0;i<N;i++)
      array[i]=i;
    cout<<"For instance, given elements are ";
    for(int i=0;i<N;i++)
      cout<<array[i];
    cout<<endl;
    int r=0;
    while(cin>>p)
    {
     cin>>q;
     if(p>=0 && p<N)
   {
    for(int i=0;i<N;i++)
     if(array[i]==p)
       array[i]=q;
      cout<<p<<" "<<q<<"  "<<r++<<"     ";
      for(int i=0;i<N;i++)
        cout<<array[i];
      cout<<"\n";
   }
  }
}
Posted on

How do align the labels with their corresponding elements?

This has been bugging me for quite some time, but I have this page (https://fiftyallstars.com/value.html)) that has 4 labels for 4 sliders. The problem is I can't make the labels line up correctly for both the desktop view AND the mobile view.

Do I have to fix this with two separate css files for both orientations, is it a absolute/relative positioning thing, or is it something else entirely? I know you can view the source on the site, but I'll put it below as well in case that's easier. Thanks a ton for your time.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">

<meta content='https://fiftyallstars.com/Images/priority.jpg' property='og:image'/>
<meta content='What are your priorities?' property='og:description'/>
<link href='https://fiftyallstars.com/Images/priority.jpg' rel='icon' type='image/x-icon'/>
<link rel="apple-touch-icon-precomposed" sizes="57x57" href="https://fiftyallstars.com/Images/Logo/50whiteonblack.jpg" />


<link href="https://fonts.googleapis.com/css?family=Oswald&display=swap" rel="stylesheet">

<style>
body{
    font-family:font-family: 'Oswald', sans-serif;
}
h1{
    color:red;
    font-size:40px;
    margin-bottom:10px;
    margin-left:-50px;
    font-variant:small-caps;
}
h2{
    color:red;
    font-size:15px;
    margin-bottom:10px;
    margin-left:-50px;
    font-variant:small-caps;
    width:400px;
    text-align:justify;
}
    input{
        margin-top:0px;
        border:none;
        font-size:25px;
        color:red;
        text-shadow:  2px 1px 3px black;
    }
    .slider{
        margin:30px 0px;
    }
</style>


<title>VALUE</title>
<script>
  window.console = window.console || function(t) {};
</script>
<script>
  if (document.location.search.match(/type=embed/gi)) {
    window.parent.postMessage("resize", "*");
  }
</script>
</head>
<body translate="no">
<html>
<center><h1>What are Your Priorities?</h1><table width="900" style="margin-top:10px;"><tr><td>
<table align="right" style="font-weight:bold; font-variant:small-caps; letter-spacing:1px; font-size:15px; padding:10px 0px 10px 35px; height:275px;"  border="0"><tr><td align="right" valign="top">Making Players Better</td></tr><tr><td align="right" valign="center">Winning Games</td></tr><tr><td align="right" valign="center">Making Money</td></tr><tr><td align="right" valign="bottom">Showcasing Talent</td></tr></table></td>
<td height="145" cellpadding="5">
<div id="app">
<div class="slider-container">
<div class="slider" v-for="option, index in Sliders">
<input type="range" :id="'slider'+index" :min="min" :max="max" v-model.number="Sliders[index]" @input="changeSlider(index)" step="0.01">
<input type="number" :value="Math.round(Sliders[index])" @change="changeBox(index, option, $event)">
</div>
</div>
</div>
</td></tr></table>
<h2>While there's nothing wrong with striving for all 4, one may efficiently maximize the potential gains in any one category by sacrificing the others.</h2>
</center>
</body>
</html>
<script src="https://static.codepen.io/assets/common/stopExecutionOnTimeout-9bf952ccbbd13c245169a0a1190323a27ce073a3d304b8c0fdf421ab22794a58.js"></script>
<script src='https://cdnjs.cloudflare.com/ajax/libs/vue/2.2.4/vue.min.js'></script>
<script src='https://cdnjs.cloudflare.com/ajax/libs/jquery/3.2.1/jquery.min.js'></script>
<script id="rendered-js">
var app = new Vue({
  el: '#app',
  data: {
    max: 100,
    min: 0,
    selectedAnswer: [],
    Sliders: [25, 25, 25, 25] },

  computed: {},


  methods: {
    changeSlider(slider) {
      const sum = this.Sliders.reduce((sum, val) => sum + val, 0);
      const diff = sum - 100;
      let remainder = 0;
      let arr = [];

      for (let i in this.Sliders) {
        if (i != slider) {//don't modify the slider which is being dragged
          let val = this.Sliders[i] - diff / (this.Sliders.length - 1);
          if (val < 0) {
            remainder += val;
            val = 0;
          }
          this.$set(this.Sliders, i, val);

        }
      }

      if (remainder) {
        const filteredLength = this.Sliders.filter((val, key) => val > 0 && key != slider).length;
        for (let i in this.Sliders) {
          if (i != slider && this.Sliders[i] > 0) {
            this.$set(this.Sliders, i, this.Sliders[i] + remainder / filteredLength);
          }

        }

      }

      this.$emit('input', this.Sliders);

      //convert to rounded values
      for (let i in this.Sliders) {
        arr.push(Math.round(this.Sliders[i]));
        this.selectedAnswer = arr;
      }

    },
    changeBox(slider, value, e) {

      console.log(slider);
      console.log(value);
      console.log(e.target.value);

      this.Sliders[slider] = Math.round(e.target.value);
      this.changeSlider(slider);

      console.log(this.Sliders);


      /*
                                 const sum = this.questionData.options.reduce((sum, val) => sum + val, 0);
                                 const diff = sum - 100;
                                 let remainder = 0

                                 for(let i in this.questionData.options){
                                        if(i != box){ //don't modify the slider which is being dragged
                                        let val = this.questionData.options[i] - diff / (this.questionData.options.length - 1)
                                        if(val < 0){
                                            remainder += val
                                          val = 0
                                        }
                                        this.$set(this.questionData.options, i, val)
                                      }
                                 }      */
    } } });
//# sourceURL=pen.js
    </script>
</body>
</html>
Posted on

Adaline Explained With Python Example

In this post, you will learn the concepts of Adaline (ADAptive LInear NEuron), a machine learning algorithm, along with a Python example. Like Perceptron, it is important to understand the concepts of Adaline as it forms the foundation of learning neural networks. The concept of Perceptron and Adaline could found to be useful in understanding how gradient descent can be used to learn the weights which when combined with input signals is used to make predictions based on unit step function output.

Here are the topics covered in this post in relation to Adaline algorithm and its Python implementation:

Posted on

Redis Is Not Just a Cache

Do You Always Need a Classic Database?

For some time now the huge amount of data that needs to be processed forces any app to have a caching strategy in front of the databases. The databases, even with huge underline optimizations, can’t always provide enough speed and availability. The main reason is that the farther is the data, the harder it is to access it. Another reason is that usually, a database persists data on disk and not on RAM. They do have embedded cache on RAM for increasing the optimizations but, even so, having a dedicated separated cache is a well-used strategy.

The usual solution to solve the performance issues when accessing a database is caching. Caching isn’t new. Caching actually means to keep a smaller amount of data that you frequently access closer to you. We have caches on processors, databases have embedded caches also and you can even code your own cache in your app. 

Posted on

Augmented Analytics With PySpark and Sentiment Analysis

In this tutorial, you will learn how to enrich COVID19 tweets data with a positive sentiment score.You will leverage PySpark and Cognitive Services and learn about Augmented Analytics.

What Is Augmented Analytics?

According to Gartner's report, augmented analytics is the use of technologies such as machine learning and AI to assist with data preparation, insight generation. Its main goal is to help more people to get value out of data and generate insights in an easy, conversational manner. For our example, we extract the positive sentiment score out of a tweet to help in understanding the overall sentiment towards COVID-19.

Posted on

Observability 101: Terminology and Concepts

When I first started following Charity on Twitter back in early 2019, I was quickly overwhelmed by the new words and concepts she was discussing. I liked the results she described: faster debugging, less alert fatigue, happier users. Those are all things I wanted for my team! But I was hung up on these big polysyllabic words, which stopped me from taking those first steps toward improving our own observability.

This post is my attempt to help orient folks who want to learn more about observability but maybe feel overwhelmed or intimidated by the vocabulary list, like I did. My goal is to get everyone on the same page about what these words mean so that we can focus on leveraging the tools and ideas to build better software and deliver more value! 

Posted on

Covid stats website

Has anyone come across any test creative websites that graph, chart, or otherwise document trends of Covid cases in a unique or interesting way?

Posted on

Get The Most Out of Media with Mediastack

Breaking news is not always easy to keep track of, especially if you’re the one that’s supposed to report it.

With news stories happening as we speak, all over the world, how are you meant to not only keep track but document it in an efficient way?

The answer to that question is a free, simple REST API for live news and blog articles. The answer is Mediastack. 

What is Mediastack?

Mediastack is a scalable JSON API that delivers world-wide news, headlines, and blog articles.

By using their easy-to-implement REST API, you can have news information of any type delivered to you on a silver platter from over 7500 different news sources.

Features

Being such an incredible API, Mediatsack comes with every feature that you could possibly need to get the job done. 

Real-time news data – Gather real-time news data from major news sources around the world, as it’s happening. Don’t wait for the news to come to you, have Mediasack retrieve it for you.

Historical news data – Not only can Mediastack retrieve news as it’s happening, but it can retrieve historical documented news data as well.

New headlines – Grab the latest and greatest headlines from articles and other news sources from all over the world.

7,500+ News sources world-wide – Mediastack collects information and data from over 7,500 news sources all over the world. With over 50+ countries currently supported, you can rest assured that you are getting every angle. 

13 languages supported – With news happening all over the world, Mediastack gathers from news sources in 13 different languages. 

Scalable JSON REST API – Mediastack’s REST API is built on a scalable apilayer cloud infrastructure and delivers news results in a lightweight and easy-to-use JSON format.

Pricing

Mediastack offers a variety of subscription-based plans that are sure to meet anyone’s needs, starting with a free-plan, and moving all the way up to custom, enterprise-level packages.

With the free plan, you get all the basics and access to all their news sources. With this plan, the news data is slightly delayed, but still reliable and, of course, free.

As you move through pricing plans, features and benefits become richer, and all the news data is live as it’s happening. Like many SaaS companies, pricing becomes significantly cheaper if billed yearly instead of monthly.

When you get to the custom pricing level, you have the option to basically get unlimited news data with zero restrictions. This is very helpful if you need to sort through a lot of news data quickly.

Conclusion

The Mediastack API was built to be extremely powerful yet scalable and easy-to-use while delivering live world-wide data. The REST API makes it easy to collect and understand data as it’s coming in JSON format. 

With Mediastack, the conclusion is simple: there’s nothing else like it. It is both intuitive and easy to use, basically giving you news data without you having to lift a finger.

If this is something you’re interested in, you definitely have to check Mediastack out. Sign up for the free package and test it out for yourself. 

Read More at Get The Most Out of Media with Mediastack

Posted on

Inspirational Websites Roundup #19

Today I’d like to share another hand-picked selection of really great website designs that will definitely give you an inspirational boost for your creativity.

Big intro type is totally in and some experimental layouts are giving a nudge to conventional structures. Lines are à la mode this season, on buttons or just as decoration!

I hope this collection updates you on some current trends and gives you some fresh inspiration for your next projects.

Ville de Varennes

Project Turntable

adidas – CHILE20

GUSTO.PLAY

Nahel Moussi

Simon Daufresne

Brews & Grooves

MUTEK Montreal

Fledge

2°C EARTH

Folklore

Gianluca Armenio

UDATSU

Metmuseum

Celebrating 10 Years with Blind Barber

Mollydooker Wines

Discover The Bartlett Summer Show 2020

Our culture — Locomotive

Fuoripista

Language Dept.

S5-Studios

When we were kids

Æbele Interiors

VOGUE FASHION`S NIGHT IN 2020

Monsieur M

Robin Noguier

Mezcal Rosaluna

Glue Lock

Kirk Whayman

Twoo

Glenn Catteeuw

kuwana

mariosmaselli

Seal + Co Professional Accountants

Atelier.M

The post Inspirational Websites Roundup #19 appeared first on Codrops.

Posted on

How to Send Emails from a Different Address (Alias) with Gmail

Say you have two email accounts - personal@gmail.com and work@company.com - the former is your personal email address while the latter is your work (corporate) email address. You are logged into your personal Gmail account but would like the mail merge to go out from your work account.

Consider another scenario where the personal secretary needs to sends out emails on behalf of her boss. So she runs the merge while staying logged into her own Google account but the recipients will see her boss’s email as the sender.

Both these scenarios can be easily handled in Mail Merge and Document Studio by setting up aliases in Gmail.

You can even send emails from your Outlook, Yahoo or Zoho email addresses through aliases in Gmail. Students and teach can send emails from their @school.edu email address while logged into their personal email accounts.

How to Setup Email Aliases in Gmail

Open gmail.com on your desktop computer, go to Settings, click the Accounts tab and, under the “Send mail as” section, click the link that says “Add another email address.”

Gmail Add Email Address

Next, follow the wizard to add the other email address as an alias to your current email address. You need to specify the sender’s name, the email address on behalf of which you wish to send out th emails and the reply-to address (optional).

Gmail Alias Setting

Treat as an alias - Yes or No?

If you own both email accounts, check the “treat as alias” option and emails sent to either address will arrive in the same Gmail inbox.

If you are sending emails on behalf on another person, say a secretary sending emails on behalf of his or her boss, the option should be unchecked. When the recipient replies to messages you send from the alias, the To: field in their reply message will be filled with your alias email address.

Gmail Verification

Gmail will send a verification code to your other email address that you wish to add as an alias to verify whether you really own or have access to that email account.

Verification Email Link

Log in to your other Gmail account and open confirmation email. Copy the confirmation code and paste it into alias verification box. Your other email address will now be added as an alias to your primary email address.

Change the Email Sender

This is how you can send emails from a different address in Google Sheets.

Mail Merge for Gmail

Send Email from Alias

Open your Google Sheet, choose Addons > Mail Merge with Attachments > Configure to open the merge sidebar. Expand the “Sender’s Email” dropdown and it will have a list of all email aliases that are connected to your Gmail account.

You can now send personalized emails on behalf of any email address that you own or have verified as an alias.

Document Studio

Open Google Sheet, go to Add-ons > Document Studio > Open. Expand the Mail Merge section and click on edit to open the Email Template designer. You’ll have an option to change the email sender as shown in the screenshot below:

Change Email Sender

Error - Cannot Add Aliases in Gmail

Are you getting an error while adding an alias in Gmail?

You must send through gmail.com SMTP servers you can send as abc@work.com. However, this functionality is not available for your account. Please contact your domain administrator.

If you do not see an option to add aliases in your Gmail settings, it is likely because your Google Workspace (GSuite) domain administrator has disabled the option to send email from aliases in domain settings.

To enable email sender aliases in Google Works, ask the admin to:

  1. Sign into the Google Admin console admin.google.com.
  2. From the dashboard, go to Apps > GSuite > Gmail > End User Access.
  3. Turn on the “Allow per-user outbound gateways” setting that says “Allow users to send mail through an external SMTP server when configuring a “from” address hosted outside your email domains.”

Save the settings and wait for about 30-60 minutes for the changes to propagate. You’ll then be able to added external email addresses as aliases in your Google Workspace email account.

Google Workspace Email Setting Send from a different email address in Google Workspace