Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In the 2020 COVID pandemic, most enterprises have realized the importance of creating an effective digital presence. While some businesses used digital presence to promote their services and business continuity, other companies used the latest trends to stay ahead among competitors. One of the most popular and widely used platforms is Node.JS, which is widely used for the development process.
What is Node.JS?
CRI-O and Podman have been widely adapted by most of the modern container platforms. In this blog, I will explore why everybody is gaga about this new ecosystem of tools/utilities and share some of my experience in this series.
I got a lot of feedback, after I published my blog on Containers and evolution of Containers (you can read it here 'Evolution of k8s worker nodes - CRI-O'). One of the common questions asked, is how Podman is different from Docker and how the new ecosystem of podman+buildah+cri-o+skopio different from what we do with docker... so I wanted to do a deep dive on these things, and share some of my experiences with this new ecosystem of container runtime and management tools/utilities.
I think code review is one of the best sources of inspiration. I see it as an opportunity to learn new things from other software developers sending pull/merge requests. Moreover, sometimes you may need to study a specific subject with more details regarding the under review code. Usually, this process leads to a more profound knowledge of that domain. However, there’s still another fact about code review: after a while, you face some common mistakes. Recently, I reviewed a feature in which I saw an Optional pitfall. Honestly, I had seen that issue several times in different merge requests sent by several developers (from beginners to experienced ones).
I know that there are tonnes of articles regarding Java Optional, some of which are quite useful like this one (although I have arguments against some of the cases mentioned in the article) by Anghel Leonard, the author of Java Coding Problems. I don’t want to repeat all of the contents you can simply find by googling. I intend to talk about some of the most common and least addressed pitfalls regarding Optional usage.
Technology is evolving rapidly; therefore, web developers need to stay updated with the ongoing developments and trends, as it is one of the most crucial aspects for the success of businesses.
There are over 1.74 billion websites around the world. Companies are seen to be competing with one another for the top rank on the search engine. The reason why developers should know and discover more innovative ways to web development as it helps businesses to grow rather exponentially and globally.
Web scraping is the process of extracting data from a website or other source of information. The action is conducted because data isn’t that easily available. The online platform has pools of information that may or may not be easily accessible. Data that is accessible, however, cannot be downloaded.
Interesting Read: What is Web Scraping: Introduction, Applications and Best Practices
Java is one of the most used languages in the world and the most successful language in the field of IT. This programming language owes its runaway success to WORA (write once, run anywhere), an important feature that removes the platform dependencies during application execution.
In older days, Java was easy to understand, write, compile, learn, and debug, which allows you to design modular programs and reusable resources.
Synching up events and appointments onto a calendar can be an arduous task. Luckily there are some handy programmatic tools, such as APIs, to help developers create and enhance calendar applications.
A Calendars API is an Application Programming Interface that enables developers to access and integrate Calendars functions and data with their own applications.
If there was a common theme that held humanity together in 2020, it was that most of us agreed that the year was nothing short of a dumpster fire. That and sweatpants.
As people learned to cope with a new reality in the Covid-19 era, the WordPress community has been a beacon of hope. When other industries needed to learn how to work remotely, we were already ahead of the pack and willing to help. As people dealt with the stress of not having meetups in person, the WordPress community thrived with online events.
The early year was tough. From toilet paper shortages to being unable to work from a favorite coffee shop, the pandemic took its toll.
However, we have learned to cope throughout the year. We used new ways to communicate from a distance. Created new circles of friends. Found extra time for long-forgotten hobbies online and off.
We continued to create art, which is the thing that makes our species so undeniably unique.
Maybe it is all the lessons we have learned through the past several months. Perhaps it is that a new year is upon us. The winds of change feel like they are gently nudging us forward.
Over the past couple of months, I have noticed a new calmness. A new hopefulness. A feeling that we will continue to rise above any challenges that come our way. While death and illness are still a part of our daily reality, we must continue to lean on the people within communities like WordPress for support. We will continue marching ahead together.
I always like to take stock of the past year. This helps keep me grounded and remain optimistic about the future. The following is a look back at 2020 for WP Tavern and WordPress.
We have had a solid year of publishing here at the Tavern. Our team, including guest authors, wrote 401 posts. In 2019, we knocked out 382. Next year, I expect that figure to increase.
Our word count average soared. This year, we averaged 790 words per post. In 2019, that number was 589. While word count is not a testament to quality writing, we did have opportunities to dive deeper into topics than before. In total, we wrote over 315,000 words. That is about 80,000 words shy of Brandon Sanderson’s The Way of Kings. You could say that we wrote enough to fill an epic fantasy novel.
“Likes” were up this year too. We went from an average of 7.0 likes per post in 2019 to 8.7 in 2020.
For comments, it is hard to gauge. The WordPress.com Stats feature does not seem to be accurately tracking our comment counts. The figure is nowhere close to correct. By my rough estimate (counting in hundreds), we have at least twice as many published comments as the data shows.
There were a few days scattered throughout the year in which we came within a hair’s breadth of surpassing the site’s all-time daily view count. But, alas, we fell just shy of the mark. Maybe next year.
The following is a list of the 10 most-viewed posts published this year. They are not necessarily representative of our best work. However, they do represent what folks were reading. Everything beyond this was pretty close in terms of stats.
For some reason, Sarah’s piece on adding subscript and superscript characters from 2014 always sneaks its way into the most-viewed posts of the year. It was technically #6 on the list, but it wasn’t published in 2020.
It was the year that saw the rise of online-only WordCamps. What started with WordCamp Asia canceling its inaugural event in February ended with Matt Mullenweg giving the annual State of the Word virtually, a first. WordCamp Europe took its massive event online for 2020 while WordCamp U.S. canceled its planned virtual get-together after months of pandemic stress and online event fatigue.
We saw the community rise up and tackle problems from the beginning. Companies like Wordfence, Yoast, and GoDaddy provided help for those who were not refunded travel expenses after cancellations. At the end of the day, that is what the WordPress community is all about: people helping other people.
WordPress kept chugging along, despite the stressful year. The big highlights were three major releases of the software:
WordPress also turned 17 this year. Its step into adulthood next year should be an adventure.
Rather than focusing too much on the work that Sarah and I have put into the Tavern this year, I want to say thank you to our contributing writers. They managed to fill some gaps when we were unable to throughout the past 12 months. They have added viewpoints outside of our own, enriching the content that our site offers. If anything, I want to see further contributions from a wider range of the WordPress community in the future.
I do not typically like to play favorites with our guest writers, but Francesca Marano’s piece titled A Non-Technical Release Lead’s Journey to Becoming a Mentor for WordPress Core Development was one of my favorite reads of the year. Her backstory is a good intro to the article. Her depth of knowledge and insight into the room where it happens makes it a must-read for anyone unfamiliar with how WordPress gets made.
Chris Maiorana’s WordPress University Was Always Online is a reminder that the education we need to excel in the online business market is but at our fingertips. It also touches on how the pandemic has allowed more people to realize that the traditional college experience is not the only path forward. It is a great piece that forces us to explore alternatives. And, these alternatives have always been available in the WordPress ecosystem.
Maiorana’s piece on the State of the Meetup Under Lockdown explores how the virtual realm has changed meetups. Bringing Back Blogs in the Age of Social Media Censorship is a look into how blogs are the answer in the age of censorship, even when we disagree with a person’s position on a subject.
On the technical end of things, Jonathan Bossenger wrote an in-depth piece for Getting Your WordPress Plugins and Themes Ready for PHP 8. He goes through everything that developers need to know to get their projects updated. The article also provides tools and resources to make things easier.
While the year might not have been ideal in many ways, there were some great moments. As I reflect upon the events of the last 12 months, I do not see a complete dumpster fire. There was a lot of good that came out of it. The world has changed in some large ways. Our societies have undergone some subtle reshaping. I do not know what 2021 holds, but I remain optimistic.
I look forward to another year covering the events surrounding WordPress. I hope you continue down this journey with the WP Tavern team.
Heck of a year, eh? Like we do every year, I’d like to give you a huge thanks for reading CSS-Tricks, and recap the year. More downs than ups, all told. Here at CSS-Tricks, it was more of a wash. Allow me to me share some numbers, milestones, and thoughts with you about our journey of 2020.
The site saw 94m pageviews this year. Last year we lost a smidge of pageviews (from 91m to 90m), so it’s nice to see that number go back up again, setting a new high record. Now I don’t have to tell myself stories like “jeez usage of browser extensions that block Google Analytics must be up.” Hitting 100m pageviews will be a nice milestone some future year. This number, long term, climbs very slowly. It’s a good reminder to me how much time, money, and energy are required to just maintain the traffic to a content site, let alone attempt to drive growth.
I have Cloudflare in front of the site this year. I think that’s a good idea generally, but especially now that they have specific technology to make it extra good. I’m a fan of pushing as much to the edge as we can, and now it’s not only static assets that are CDN-served but the content as well.
I mention that because now I have access to Cloudflare analytics, so I can compare across tools. I can’t see a whole year of data on Cloudflare, but comparing last month’s unique visitors between the two services, I see 6,847,979 unique visitors on Cloudflare compared to 6,125,272 sessions (or 7,449,921 unique page views — I’m not sure which is directly comparable) on Google Analytics. They seem pretty close. Closer than I thought they would be, since Google Analytics requires client-side JavaScript and Cloudflare analytics are, presumably, gathered at the DNS level, and thus not blockable like client-side JavaScript. I’ve turned off the WordPress-powered analytics for now, as having three places for analytics seemed a bit much, although I might flip them back on because, without them, I can’t see top on-site search results, which I definitely like to have.
Traffic that comes from organic¹ search was 77.7% this year, versus 80.6% last year. A 3% swing feels pretty large, yet almost entirely accounted for by a 3% swing from 9% to 12% in “direct” traffic. I have no idea what to make of that, but I suppose I don’t mind a better diversification in sources.
I find these end-of-year looks at the numbers sorta fun, but I’m generally not a big analytics guy. Last year I wrote:
There is a bunch of numbers I just don’t feel like looking at this year. We’ve traditionally done stuff like what countries people are from, what browsers they use (Chrome-dominant), mobile usage (weirdly low), and things like that. This year, I just don’t care. This is a website. It’s for everyone in the world that cares to read it, in whatever country they are in and whatever browser they want to.
I feel even more apathetic toward generalized analytics numbers this year. I think analytics are awesome when you have a question in mind you want an answer to, where the numbers help find that answer. Or for numbers that are obviously important and impactful to your site that you determined for yourself. Just poking around at numbers can fool you into thinking you’re gathering important insights and making considered decisions when you’re kinda just picking your nose.
One question that does interest me is what the most popular content is by traffic (we’ll get to that in a bit). Looking at the most popular content (by actual traffic) gives me a sense of what brings people here. Bringing traffic to the site is a goal. While we don’t generally sell sponsorship/advertising based on page views directly, those numbers matter to sponsors and fairly correlate directly to what we can charge.
Another bit of data I care about is what people search for that bring them to the site. Here’s how that breaks down:
From there, 10-100 are “random specific CSS things.” Beyond 100 is where SVG, JavaScript, design stuff, and CSS are sprinkled into the mix. The 251st ranked search term is the first time React shows up. The insight here is that: (1) our layout guides continue to do very well, (2) a lot of people like to get to the site first, then find what they need, and (3) searches for library-specific content isn’t a particularly common way to land here.
Thanks to Jacob, we can look at analytics data based on the year the content was written (and a few other bits of metadata).
Here’s an interesting thing. In 2019, articles written in 2019 generated about 6.3m page views. Those same articles, in 2020, generated 7.3m page views. Neat, huh? The articles drove more traffic as they aged.
Articles written in 2020 generated 12m pageviews. Here’s the top 10:
Interesting backstory on that list. I dug into Google Analytics and created that Top 10 list based on the data it was showing me in a custom report, which Jacob taught me to do. Serendipitously, Jacob emailed me right after that to show me the Top 10 that he calculated, and it was slightly different than mine. Then I went back and re-ran my custom report, and it was slightly different than both the others. Weird! Jacob knew why. When you’re looking at a huge dataset like this in Google Analytics, they will only sample the data used for the report. It will show you a “yellow badge” and tell you what percentage of the data the report is based on. 500,000 sessions is the max, which is only 0.7% of what we needed to look at. That’s low enough that it accounted for the different lists. Jacob had already done some exporting and jiggering of the data to account for that, so the above list is what’s accurate to 100% of all sessions.
The top articles on the entire site from any year:
Nothing from the Almanac made the top 10, but interestingly, right after that, the next 20 are so are heavily sprinkled with random articles from there. All told, the Almanac is about 14.8% of all traffic.
Two other things that I think are very cool that we did with content is:
One of the many reasons I love being on WordPress is how easy it is to spin up series like these. All we did was toss up a category-specific template file and slapped on a little custom CSS. That gives the posts a cool landing page all to themselves, but are still part of the rest of the “flow” of the site (RSS, search, tags, etc.).
Perhaps the slight increase in traffic was COVID-related? With more people turning to coding as a good option for working from home, maybe there are more people searching for coding help. Who knows.
What we definitely found was that nearly every sponsor we work with, understandably, tightened their belt. Add in advertising plans with us that were reduced or canceled and, as a rough estimate, I’d say we’re down 25% in sponsorship revenue. That would be pretty devastating except for the fact that we try not to keep too many eggs in one basket.
Feels like a good time to mention that if your company is doing well and could benefit from reaching people who build websites, let’s talk sponsorship.
I’m trying to diversify revenue somewhat, even on this site alone. For example…
We’ve been using WooCommerce here to sell a couple of things.
Posters, mainly. A literal physical bit of printed paper sent through the post to you. The posters are unique designs made from the incredible illustrations that Lynn Fisher created for the flexbox and grid guides. We essentially “drop ship” them, meaning they are printed and shipped on-demand by another company. So, you buy them from this site, but another company takes it from there and does all the rest of it. That’s appealing because the amount of work is so low, but there are two major downsides: (1) Customer support for the orders becomes our problem and I’d say ~20% of orders need some kind of support, and (2) the profit margin is fairly slim compared to what it would be if we took on more of the work ourselves.
We also sell MVP Supporter memberships, which are great in that they don’t require much ongoing work. The trick there is just making sure it is valuable enough for people to buy, which we’ll have to work more on over time. For now, you basically get a book, video downloads, and no ads.
For being an MVP supporter of CSS-Tricks, you get: No ads, extra content, easier commenting, and extreme satisfaction for being cool.
Loose math, eCommerce made up 5% of the lost revenue. Long way to go there, but it’s probably worth the journey as my guess is that this kind of revenue is less volatile.
I’m also still optimistic about Web Monetization in the long-term (here’s the last post I wrote on it). But right now, it is not a solution that makes for a significant new revenue stream. Optimistically, it’s something like 0.05% of revenue.
As far a website traffic driver goes, social media isn’t particularly huge at 2.2% of all traffic (down from 2.3% last year). That’s about where it always is, whether or not we put much effort into it over the course of a year, which is exactly why I try not to spend energy there. What little effort we do expend, 95% of it is toward Twitter. We lean on Jetpack’s social automation features, mostly. It is still cool to have @css as a handle, and we are closing in on half a million followers. You’d think that would be worth something. We’ll have to figure that out someday.
When we hand-write Tweets (rare), those are still the ones with the most potential. I only do that when it feels like something fun to do, because even though they can get the most engagement, the time/value thing still just doesn’t make it worthwhile.
Most of our tweets are just auto-generated when a new post is published. And we’ve been doing that for so long, I think that’s what the Twitter followers largely expect anyway, and that’s fine. We do have the ability to customize the Tweet before it goes out, which we try to, but usually don’t.
The other 5% of effort is Instagram just because it’s kinda fun. I don’t even wanna think about trying to extract direct value from Instagram. Maybe if we had a lot more products for direct sale it would make sense. But for now, just random tips and stuff to hold an audience.
I did 22 screencasts this year. That’s a lot compared to the last many years! I’m not sure if I’ll be as ambitious in 2021, but I suspect I might be, because my setup at my desk is getting pretty good for doing them and my editing skills are slowly improving. I enjoy doing them, and it’s an occasional income stream (my favorite being pairing up with someone from a company and digging into their technology together). Plus, we got that cool new intro for our videos done by dina Amin.
The screencasts are published on the site and to iTunes as a videocast, but the primary place people watch is YouTube. I guess we could consider YouTube “social media” but I find that screencasts are more like “real content” in a way that I don’t with other social media. They are certainly much more time-consuming to produce and I hope more evergreen than a one-off tweet or something.
We hit 81,765 subscribers to the newsletter. On one hand, that’s a respectable number. On the other, it’s far too low considering how gosh darn good it is! I was hoping we’d hit 100k this year, but I didn’t actually do all that much to encourage signups, so that’s on me. I don’t think we missed a single week, so that’s a win, and considering we were at 65,000 last year, that’s still pretty good growth.
Y’all left 4,322 comments on the site this year. That’s down a touch from 4,710, but still decent averaging almost 12 a day.
I rollercoaster emotionally about comments. One day thinking they are too much trouble, requiring too much moderation and time to filter the junk. The vitriol can be so intense (on a site about code, wow) that some days I just wanna turn them off. Other times, I’m glad for the extra insight and corrections. Not to mention, hey, that’s content and content is good. We’ve never not had comments, so, hey, let’s keep ’em for now.
I absolutely always encourage your helpful, insightful, and kind comments, and promise to never publish rude or wrong comments (my call).
The forums completely shut down this year (into “read only” mode), so commenting activity from that didn’t exactly make its way over to the blog area. Closing the forums still feels… weird. I liked having a place to send (especially beginners) to ask questions. But, we just do not have the resources (or business model) to support safe and active forums. So closed they will remain, for now.
place-items in there, but not place-content or place-self. Then there is esoteric stuff, like :current, :past, and :future time-dimensional pseudo-classes which, frankly, I don’t even really understand but are a thing. If you wanna help, please reach out. Thank you, again, for being a reader of this site. I hope these little peeks at our business somehow help yours. And I really hope 2021 is better than 2020, for all of us.
🧡
The post Thank You (2020 Edition) appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
For those of us as Flutter developers, we already know that flutter does not provide a layout design file for the project. So, sometimes we have a little trouble designing the layout display design.
Tools needed:
Sketch
In this article, we will see how quickly we can setup Grafana and Prometheus with Strimzi. So let us quickly go through the steps required for this setup.
1. Start Minikube.
All of it starts with an idea. After that, execution comes into the picture. For better results, the execution must be in such a way that reduces the risk. And also increases productivity.
Mobile app development has become so subsequent in recent years. Also, the product quality has become so consequential too. As a result, to secure market leadership companies need to focus on various things instead of relying on network effects.
gv$sqltextSELECT DISTINCT obj.object_name
,program_line#
, cpu_time / 1000000 AS cpu_time_in_secs
, elapsed_time / 1000000 AS elapsed_time_in_secs
,buffer_gets
,disk_reads
,end_of_fetch_count AS rows_fetched_per_execution
,executions
,optimizer_cost
,vsql.sql_id
,NULL operation
,NULL options
,vsplan.plan_hash_value
,sql_text
, ( SUBSTR ( DBMS_LOB.SUBSTR ( sql_fulltext
,4000
,1
)
, INSTR ( DBMS_LOB.SUBSTR ( sql_fulltext
,4000
,1
), '/*' ) + 2
, INSTR ( DBMS_LOB.SUBSTR ( sql_fulltext
,4000
,1
), '*/' ) - INSTR ( DBMS_LOB.SUBSTR ( sql_fulltext
,4000
,1
), '/*' ) - 2
)
) release_string
,NULL error_flag
,NULL error_message
,loads
,first_load_time
,user_io_wait_time
,rows_processed
,last_load_time
,vsql.module
,fnd_global.user_id created_by
,SYSDATE creation_date
,fnd_global.user_id last_updated_by
,SYSDATE last_update_date
,'-1' last_update_login
FROM gv$sql vsql
,gv$sql_plan vsplan
,all_objects obj
WHERE 1 = 1
AND vsql.sql_id = vsplan.sql_id
AND vsql.sql_fulltext NOT LIKE '%sql_text%'
AND vsql.program_id = obj.object_id(+)
AND vsql.sql_fulltext LIKE lv_pattern
AND TO_DATE ( last_load_time, 'YYYY-MM-DD/HH24:MI:SS' ) >= ( SYSDATE - p_hours_from / 24 )
AND nvl(obj.object_name, '-') = NVL(p_program,nvl(obj.object_name, '-'))
AND nvl(vsql.module, '-') = NVL(p_module,nvl(vsql.module, '-'))
ORDER BY last_load_time DESC;
fnd_file.put_line(fnd_file.output, 'String..') – This can be used to print the SQL plan in a concurrent program output file.
In order to hit the right chord with your potential customers, it is critically important to dig deep into the latest innovations and keep your Magento 2 store ready by adopting the latest Magento development trends.
Here are the top 5 Magento development trends that you should consider adopting into your Magento 2 eCommerce store in 2021.
Eleventy is increasing in popularity because it allows us to create nice, simple websites, but also — because it’s so developer-friendly. We can build large-scale, complex projects with it, too. In this tutorial we’re going to demonstrate that expansive capability by putting a together a powerful and human-friendly environment variable solution.
Environment variables are handy variables/configuration values that are defined within the environment that your code finds itself in.
For example, say you have a WordPress site: you’re probably going to want to connect to one database on your live site and a different one for your staging and local sites. We can hard-code these values in wp-config.php but a good way of keeping the connection details a secret and making it easier to keep your code in source control, such as Git, is defining these away from your code.
Here’s a standard-edition WordPress wp-config.php snippet with hardcoded values:
<?php
define( 'DB_NAME', 'my_cool_db' );
define( 'DB_USER', 'root' );
define( 'DB_PASSWORD', 'root' );
define( 'DB_HOST', 'localhost' );Using the same example of a wp-config.php file, we can introduce a tool like phpdotenv and change it to something like this instead, and define the values away from the code:
<?php
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();
define( 'DB_NAME', $_ENV['DB_NAME'] );
define( 'DB_USER', $_ENV['DB_USER'] );
define( 'DB_PASSWORD', $_ENV['DB_PASSWORD'] );
define( 'DB_HOST', $_ENV['DB_HOST'] );A way to define these environment variable values is by using a .env file, which is a text file that is commonly ignored by source control.
We then scoop up those values — which might be unavailable to your code by default, using a tool such as dotenv or phpdotenv. Tools like dotenv are super useful because you could define these variables in an .env file, a Docker script or deploy script and it’ll just work — which is my favorite type of tool!
The reason we tend to ignore these in source control (via .gitignore) is because they often contain secret keys or database connection information. Ideally, you want to keep that away from any remote repository, such as GitHub, to keep details as safe as possible.
For this tutorial, I’ve made some starter files to save us all a bit of time. It’s a base, bare-bones Eleventy site with all of the boring bits done for us.
Step one of this tutorial is to download the starter files and unzip them wherever you want to work with them. Once the files are unzipped, open up the folder in your terminal and run npm install. Once you’ve done that, run npm start. When you open your browser at http://localhost:8080, it should look like this:
Also, while we’re setting up: create a new, empty file called .env and add it to the root of your base files folder.
Environment variables are often really shouty, because we use all caps, which can get irritating. What I prefer to do is create a JavaScript interface that consumes these values and exports them as something human-friendly and namespaced, so you know just by looking at the code that you’re using environment variables.
Let’s take a value like HELLO=hi there, which might be defined in our .env file. To access this, we use process.env.HELLO, which after a few calls, gets a bit tiresome. What if that value is not defined, either? It’s handy to provide a fallback for these scenarios. Using a JavaScript setup, we can do this sort of thing:
require('dotenv').config();
module.exports = {
hello: process.env.HELLO || 'Hello not set, but hi, anyway 👋'
};What we are doing here is looking for that environment variable and setting a default value, if needed, using the OR operator (||) to return a value if it’s not defined. Then, in our templates, we can do {{ env.hello }}.
Now that we know how this technique works, let’s make it happen. In our starter files folder, there is a directory called src/_data with an empty env.js file in it. Open it up and add the following code to it:
require('dotenv').config();
module.exports = {
otherSiteUrl:
process.env.OTHER_SITE_URL || 'https://eleventy-env-vars-private.netlify.app',
hello: process.env.HELLO || 'Hello not set, but hi, anyway 👋'
};Because our data file is called env.js, we can access it in our templates with the env prefix. If we wanted our environment variables to be prefixed with environment, we would change the name of our data file to environment.js . You can read more on the Eleventy documentation.
We’ve got our hello value here and also an otherSiteUrl value which we use to allow people to see the different versions of our site, based on their environment variable configs. This setup uses Eleventy JavaScript Data Files which allow us to run JavaScript and return the output as static data. They even support asynchronous code! These JavaScript Data Files are probably my favorite Eleventy feature.
Now that we have this JavaScript interface set up, let’s head over to our content and implement some variables. Open up src/index.md and at the bottom of the file, add the following:
Here’s an example: The environment variable, HELLO is currently: “{{ env.hello }}”. This is called with {% raw %}{{ env.hello }}{% endraw %}.
Pretty cool, right? We can use these variables right in our content with Eleventy! Now, when you define or change the value of HELLO in your .env file and restart the npm start task, you’ll see the content update.
Your site should look like this now:
You might be wondering what the heck {% raw %} is. It’s a Nunjucks tag that allows you to define areas that it should ignore. Without it, Nunjucks would try to evaluate the example {{ env.hello }} part.
That first example we did was cool, but let’s really start exploring how this approach can be useful. Often, you will want your production images to be fronted-up with some sort of CDN, but you’ll probably also want your images running locally when you are developing your site. What this means is that to help with performance and varied image format support, we often use a CDN to serve up our images for us and these CDNs will often serve images directly from your site, such as from your /images folder. This is exactly what I do on Piccalilli with ImgIX, but these CDNs don’t have access to the local version of the site. So, being able to switch between CDN and local images is handy.
The solution to this problem is almost trivial with environment variables — especially with Eleventy and dotenv, because if the environment variables are not defined at the point of usage, no errors are thrown.
Open up src/_data/env.js and add the following properties to the object:
imageBase: process.env.IMAGE_BASE || '/images/',
imageProps: process.env.IMAGE_PROPS,We’re using a default value for imageBase of /images/ so that if IMAGE_BASE is not defined, our local images can be found. We don’t do the same for imageProps because they can be empty unless we need them.
Open up _includes/base.njk and, after the <h1>{{ title }}</h1> bit, add the following:
<img src="https://assets.codepen.io/174183/mountains.jpg?width=1275&height=805&format=auto&quality=70" alt="Some lush mountains at sunset" />
By default, this will load /images/mountains.jpg. Cool! Now, open up the .env file and add the following to it:
IMAGE_BASE=https://assets.codepen.io/174183/
IMAGE_PROPS=?width=1275&height=805&format=auto&quality=70If you stop Eleventy (Ctrl+C in terminal) and then run npm start again, then view source in your browser, the rendered image should look like this:
<img src="https://assets.codepen.io/174183/mountains.jpg?width=1275&height=805&format=auto&quality=70" alt="Some lush mountains at sunset" />This means we can leverage the CodePen asset optimizations only when we need them.
We can also use environment variables to conditionally render content, based on a mode, such as private mode. This is an important capability for me, personally, because I have an Eleventy Course, and CSS book, both powered by Eleventy that only show premium content to those who have paid for it. There’s all-sorts of tech magic happening behind the scenes with Service Workers and APIs, but core to it all is that content can be conditionally rendered based on env.mode in our JavaScript interface.
Let’s add that to our example now. Open up src/_data/env.js and add the following to the object:
mode: process.env.MODE || 'public'This setup means that by default, the mode is public. Now, open up src/index.md and add the following to the bottom of the file:
{% if env.mode === 'private' %}
## This is secret content that only shows if we’re in private mode.
This is called with {% raw %}`{{ env.mode }}`{% endraw %}. This is great for doing special private builds of the site for people that pay for content, for example.
{% endif %}If you refresh your local version, you won’t be able to see that content that we just added. This is working perfectly for us — especially because we want to protect it. So now, let’s show it, using environment variables. Open up .env and add the following to it:
MODE=privateNow, restart Eleventy and reload the site. You should now see something like this:
You can run this conditional rendering within the template too. For example, you could make all of the page content private and render a paywall instead. An example of that is if you go to my course without a license, you will be presented with a call to action to buy it:
This has hopefully been really useful content for you so far, so let’s expand on what we’ve learned and have some fun with it!
I want to finish by making a “fun mode” which completely alters the design to something more… fun. Open up src/_includes/base.njk, and just before the closing </head> tag, add the following:
{% if env.funMode %}
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Lobster&display=swap" />
<style>
body {
font-family: 'Comic Sans MS', cursive;
background: #fc427b;
color: #391129;
}
h1,
.fun {
font-family: 'Lobster';
}
.fun {
font-size: 2rem;
max-width: 40rem;
margin: 0 auto 3rem auto;
background: #feb7cd;
border: 2px dotted #fea47f;
padding: 2rem;
text-align: center;
}
</style>
{% endif %}This snippet is looking to see if our funMode environment variable is true and if it is, it’s adding some “fun” CSS.
Still in base.njk, just before the opening <article> tag, add the following code:
{% if env.funMode %}
<div class="fun">
<p>🎉 <strong>Fun mode enabled!</strong> 🎉</p>
</div>
{% endif %}This code is using the same logic and rendering a fun banner if funMode is true. Let’s create our environment variable interface for that now. Open up src/_data/env.js and add the following to the exported object:
funMode: process.env.FUN_MODEIf funMode is not defined, it will act as false, because undefined is a falsy value.
Next, open up your .env file and add the following to it:
FUN_MODE=trueNow, restart the Eleventy task and reload your browser. It should look like this:
Pretty loud, huh?! Even though this design looks pretty awful (read: rad), I hope it demonstrates how much you can change with this environment setup.
We’ve created three versions of the same site, running the same code to see all the differences:
All of these sites are powered by identical code with the only difference between each site being some environment variables which, for this example, I have defined in my Netlify dashboard.
I hope that this technique will open up all sorts of possibilities for you, using the best static site generator, Eleventy!
The post Give your Eleventy Site Superpowers with Environment Variables appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
As the adage goes, in software development, your code speaks for you, and that's why it is essential to write concise yet readable and performant code (there are certainly the odd exceptions to this rule, but in general, it's always better to be safe than sorry). It's always a good idea to have good code quality tools in your developer toolbox, helping you manage technical debt by writing clean and maintainable source code. In this article, we will try to list out a few interesting options you should consider. While this list is based on my subjective opinions, I hope you find it useful!
DeepSource is a static analysis tool that intelligently runs your code through tests that help you figure out issues in critical areas such as performance, anti-patterns, bug-risks, security vulnerabilities, style, and documentation issues.
Do you have the following questions when considering Serverless360 as a monitoring solution for your Azure Serverless Applications?
In real-time Azure Serverless services are put together to build orchestrations that solve critical business needs. What is required is a monitoring solution for these applications. What one can find in the Azure portal is Azure Monitor, a monitoring solution for an Azure entity. Serverless360 complements the Azure portal by providing the much-needed monitoring for serverless applications.
Amazon Web Services (AWS) is one of the most competent cloud service providers around right now. It offers a number of different kinds of storage. It provides low-cost data storage with high durability and high availability.
This article will help you to understand the different storage services and features available in the AWS Cloud and how to select the right the storage type for your ELK stack.