Monthly Archiv: July, 2020
I wanted to share with you a free chapter from my latest book, "Advanced Web Application Architecture".
I've picked Chapter 11, which gives a compact overview of all the design patterns that are useful for structuring your web application in a way that will (almost) automatically make it independent of surrounding infrastructure, including the web framework you use.
Chapter 11 is the first chapter of Part II of the book. In Part I we've been discovering these design patterns by refactoring different areas of a simple web application. Part II provides some higher-level concepts that can help you structure your application. Besides design patterns, it covers architectural layering, and hexagonal architecture (ports & adapters). It also includes a chapter on testing decoupled applications.
If you're interested in this kind of topic, make sure to get a discounted copy using this link: https://leanpub.com/web-application-architecture/c/RELEASE_DAY.
Chapter 11: Key design patterns
This chapter covers:
- A catalog of design patterns
- Implementation suggestions
- A high-level design process based on these design patterns
11.1 Framework-inspired structural elements
Every framework comes with its own set of recognized element types.
For instance, Symfony developers learn to create controllers, entities, form types, Twig templates, Yaml configuration files, and so on.
Laravel developers also create controllers, but they need among other things: models, Blade templates, and PHP configuration files.
When you take a look at the directory structure of most web application projects, you'll immediately notice the framework that's been used.
Frameworks dictate your project structure.
And frameworks also invade your code.
This all sounds like frameworks are an enemy, instead of the helpful friend they presume to be, but this is a false contradiction.
In infrastructure code, frameworks are your friend.
In core code, they are not.
If frameworks determine the structure of your core code, you'll end up with:
- Implicit use cases inside controllers,
- A domain model that's coupled to its underlying infrastructure, and in general
- Code that's coupled to the framework.
In Part I: Decoupling from infrastructure we've already seen many techniques to overcome these problems.
We were able to extract a use case from a controller by modeling it as a framework-independent service.
We extracted an entity from database interaction code.
And we decoupled code from the framework by using dependency injection everywhere, and by passing contextual information as method arguments.
In this chapter we take a closer look at the types of objects that were the result of decoupling from infrastructure.
Knowing more about the typical aspects of these objects will help you use them as building blocks instead of merely the result of refactoring activities.
By using these objects as "primitives" you can implement all of the application's use cases, without even choosing a framework.
The framework will just be the finishing touch, the bridge between your application's core and the outside world.
11.2 Entities
The first pattern to cover is the Entity pattern.
In this book the concept of an entity is the same as the concept of an aggregate in Domain-Driven Design literature.
An aggregate is an entity, including any of its child entities, and any of the value objects used inside of it.
In my experience the term "aggregate" leads to a lot of confusion so I decided to use the word "entity" in this book.
We have talked about entity design in Chapter 2: The domain model, and I've already mentioned several design rules for it there.
Still, I want this chapter to be a reference guide to the standard design patterns you'll need in decoupled application development, so I'll briefly summarize the rules here.
I'll just declare the rules without defending them in detail.
You can always look up the reasoning in Eric Evans' "Domain-Driven Design - Tackling complexity in the heart of software", Addison-Wesley Professional (2003). A quick and accurate primer on the topic is Vaughn Vernon's article series "Effective Aggregate Design".
Entities are objects that preserve the state of your application.
They are the only type of objects in your application that have persistent state.
Most of the other objects should be designed to be immutable and stateless.
Being mutable, entities should not be passed to clients that don't intend to change their state.
When a client
Truncated by Planet PHP, read more at the original (another 46211 bytes)
Ideas: the germs that grow into those great, award-winning designs we all want to have our names attached to. We all get dozens of ideas constantly, which typically range from fairly good to amazingly good. Ideas are an abundant commodity that we all have, as creative people.
In fact, most designers have more ideas than they know what to do with. Yet, most jealously hide their ideas, paranoid that someone will “steal” them and do something that will undermine their own fame as a designer.
Today, we’re going to explore some important reasons why it’s stupid to worry about anyone potentially stealing your ideas.
Ideas Mean Nothing
First of all, success is 99% execution. The sweat and hard work that go into making a design a reality is really what matters – that’s the important part. Only 1% of success is the idea. Ideas are useless on their own. We all get them – they only mean something if you make them happen. You can have ideas that are sort of ‘blah’, and yet still dominate your field through hard work.
The good news is, people who steal others’ ideas don’t realize this. They think it’s the idea itself that is valuable. But the truth is, a mediocre idea executed well is worth a lot more than a great idea executed poorly. So, if you have good ideas, and you work hard to turn them into something, you can always generate more ideas and have success as a designer.
Telling People Gives You More Ideas
Sharing your ideas will usually foster the development of new ideas. If you’re creative, that is (which you are; why else would you be reading this?). The person you share your ideas with can give you an outside perspective and some much-needed feedback about whether your idea is actually as good as you think it is.
You can also brainstorm together with others to come up with a myriad of different ideas, each one stronger than the last.
If you only have one idea, though, that’s a bad sign. It’s important to avoid ‘one-itis’ or fixating on a single idea to the exclusion of all others. You might be completely convinced that that one, single idea is the end all, be all thing that’s going to make your career, but it probably isn’t.
Success is a culmination of the little things, the daily triumphs we make each time we complete a new project that we’re proud of. So go out there and make as much work as you can.
Provide Value to Others
When you share ideas, you help the entire design community. It’s important to give back to your fellow designers who might be struggling with the same issues you did once upon a time. I’m not saying you have to give away all of your “trade secrets” (although even that’s not as taboo as it used to be).
But talking out an idea and letting others transform it in their own unique ways can inspire you as well. You might see a completely different approach to an idea that you hadn’t considered before.
Someone Else Probably Thought of It Anyway
Exactly what it says on the tin. Ideas occur simultaneously to different people all the time, often without them even knowing it. This is why some work can look strikingly similar without the designers even having heard of each other. Great minds think alike. That’s the reason you can’t legally copyright an idea. We humans are just too similar in our thought patterns.
The key is taking an idea that other people might have already explored and doing it in your own unique way, using your experiences and skills as a designer to put an unconventional spin on it. As the saying goes, everything has been done before, but not by you.
Finally, keep in mind that ideas are rarely stolen wholesale anyway. Usually, someone takes bits and pieces of ideas from various sources (or they should, anyway). As we saw earlier, everything is a remix – not a direct copy.
Very few designers who have any pride in their abilities at all will actually want to steal your idea entirely. Those are called hacks – they’re very easy to spot, and the design community doesn’t normally tolerate them for long.
The post Stop Worrying About People Stealing Your Ideas appeared first on Speckyboy Design Magazine.
Package:
Summary:
Show files and sub-folders of a folder using icons
Groups:
Author:
Description:
This package can show files and sub-folders of a folder using icons...
Read more at https://www.phpclasses.org/package/11727-PHP-Show-files-and-sub-folders-of-a-folder-using-icons.html#2020-07-21-21:27:57
WordPress 5.5 Beta 3 is now available!
This software is still in development,so it’s not recommended to run this version on a production site. Consider setting up a test site to play with the new version.
You can test WordPress 5.5 Beta 3 in two ways:
WordPress 5.5 is slated for release on August 11th, 2020, and we need your help to get there!
Thank you to all of the contributors who tested the beta 2 development release and gave feedback. Testing for bugs is a critical part of polishing every release and a great way to contribute to WordPress.
Some highlights
Since beta 2, 43 bugs have been fixed. Here are a few changes in beta 2:
- Plugin and theme versions are now shared in the emails when automatically updated (see #50350).
- REST API routes without a
permission_callback now trigger a _doing_it_wrong() warning (see #50075). - Over 23 Gutenberg changes and updates (see #24068 and #50712).
- A bug with the new import and export database Dashicons has been fixed (see #49913).
Developer notes
WordPress 5.5 has lots of refinements to polish the developer experience. To keep up, subscribe to the Make WordPress Core blog and pay special attention to the developers’ notes for updates on those and other changes that could affect your products.
How to Help
Do you speak a language other than English? Help translate WordPress into more than 100 languages!
If you think you’ve found a bug, you can post to the Alpha/Beta area in the support forums. We’d love to hear from you!
If you’re comfortable writing a reproducible bug report, file one on WordPress Trac, where you can also find a list of known bugs.
Latest PECL Releases:
Byte-sized functional programming: Immutable variables are easier to understand
An immutable variable is one whose value doesn't change after it has been first set. PHP doesn't natively support that, but we can write our classes in such a way to simulate it. For example, rather than this:
<?php
class Point
{
private int $x;
private int $y;
public function __construct(int $x, int $y)
{
$this->x = $x;
$this->y = $y;
}
public function moveUp(int $by): void
{
$this->y += $by;
}
}
?>
We can write this:
<?php
class Point
{
private int $x;
private int $y;
public function __construct(int $x, int $y)
{
$this->x = $x;
$this->y = $y;
}
public function
moveUp(int $by): Point
{
$new = clone ($this);
$new->y += $by;
return $new;
}
}
?>In the second version, once a given `Point` object is created it will never change. We can safely pass it to another function or method and be guaranteed that its value won't change without us knowing. Instead, any attempt to change it results in a new object, with its own identity, representing the new point in space. (In practice there would be other methods here as well, but we're focusing on just the mutation part.)
Code that uses immutable variables is easier to think about, because we don't have to worry about "does passing this object to this function change it?" We know it doesn't. Once we know something about an object we can guarantee that fact doesn't change. That can make a lot of subtle bugs impossible, which means we don't have to spend time looking for or correcting them.
Want to know more about functional programming and PHP? Read the whole book on the topic: Thinking Functionally in PHP.
Package:
Summary:
Store and display gallery pictures of an album
Groups:
Author:
Description:
This package can store and display gallery pictures of an album...
Read more at https://www.phpclasses.org/package/11725-PHP-Store-and-display-gallery-pictures-of-an-album.html
Sure, the thought of web developers downing caffeinated beverages by the gallon is a stereotype. But if you browse social media enough, it sure does seem like many of us partake in the ritual.
You also see various homages to that liquid lightning on CodePen. Through clever use of the latest web technologies, developers have crafted virtual drinks and the machines that make (or dispense) them. It’s clearly a love affair.
Today, we’ll take you on a caffeine-induced tour of code snippets that are sure to get you buzzing.
The Web Designer Toolbox
Unlimited Downloads: 1,000,000+ Web Templates, Themes, Plugins, Design Assets, and much more!
Make Mine a Venti
There’s a particular coffee chain that is known worldwide – we will not mention it here. But the logo is pretty recognizable and the white paper cups are ubiquitous. One crafty developer recreated both – using CSS and SVG.
See the Pen Starbucks Cup – CSS by Ellie
Soda Fountain
Maybe you’re more of a soda drinker? In that case, you’ll want to dive into this gooey drizzle of grape soda (perhaps it’s just the syrup). It’s powered by Three.js, making the animation silky-smooth. What makes the presentation even more fun is that the viewing angle is changed via the user’s cursor position.
See the Pen Grape Soda by Liam Egan
Win a Complimentary Beverage
This snippet combines the tastiness of coffee with the excitement of a casino. Pull (or click) the handle of the slot machine and see if you’re a winner (trust us, you’ll know). Through its usage of JavaScript, it seems like the odds of winning are only slightly better than that of a real machine.
See the Pen Caffeine Slot Machine by Neal Fennimore
Tea Time
We can’t forget about the delightfulness of a good cup of tea. It refreshes and energizes. This simple SVG animation makes us want to curl up with a hot cup and a good book.
See the Pen SVG Tea Mug by Chris Gannon
E is for Espresso
This one is a classic. In true children’s television fashion, an animated espresso machine forms the letter “E”. The only caveat is that espresso might not be the best drink for the kiddies – not if you want them to take a nap, anyway.
See the Pen E – Espresso by Alex Bergin
The History of Caffeine
Timeline layouts are growing in popularity and a great way to showcase a chronology. And really, there’s no better way to illustrate the history of caffeine, as done in this example. The super-clean layout makes it easy to follow and read.
See the Pen Timeline by Amy Spielmaker
Your Friendly Caffeine Vending Machine
Granted, not every beverage featured in this virtual vending machine is caffeinated. Still, rows one and three will get the job done. But there’s more! Not only can you grab a virtual Coke, you can also “drink” it as well. Burps not included.
See the Pen Coca Cola Vending Machine (Interactive) by Giovanni Hobbins
Just a Squeeze Will Do
It’s hard not to smile when you see this little coffee dispenser do its thing. Featuring ultra-smooth SVG animation, this example also adds the element of fun. It’s great inspiration for memorable branding as well.
See the Pen #1 – Coffee Machine – SVG animation with CSS3 by Jonathan Silva
Fueling Creative Energy
Maybe caffeinated beverages aren’t for everyone. But they have helped many a web designer power through projects over the years. And, ironically, they’ve also fueled some of us through the process of learning the very languages and techniques we’ve seen here today.
So, here’s a virtual glass-clink to caffeine and those who consume it while building the web. We salute you both!
Want to see more snippets to buzz about? Check out our CodePen collection.
The post 8 Caffeine-Powered CSS and JavaScript Snippets appeared first on Speckyboy Design Magazine.
Ask a dozen web designers how to build a specific feature – and you’ll likely get a dozen unique answers. That’s part of the beauty of web design. You don’t need to stick to one specific formula to achieve a desired look or functionality.
However, not every solution is on equal footing. The fact that it works nicely in the browser isn’t enough. The potential downside is that some approaches are going to be more resilient than others.
But what exactly is resiliency when it comes to web design? Let’s take a look at what makes for a resilient design (in one designer’s view, anyway). Then, we’ll discuss how resiliency can change how you approach projects.
Don’t Build a House of Cards
Have you ever built a page or even a feature that was highly dependent on a single element? Something that, if that element is changed in some way, the entire thing breaks?
It’s likely that all of us have done this at some point. For example, think of an old-school multi-column layout. Before we had CSS Grid or Flexbox, we often found ourselves trying to piece it all together with floats.
While it was possible to get it to work well enough in a browser, the whole thing was a house of cards. Accidentally removing the wrong CSS class or forgetting to use a clearfix hack led to a broken layout.
In short, this approach was not resilient. It was too easy to break and couldn’t adapt well to future changes. Eventually, it’s likely we’d have to rebuild the layout to better handle different scenarios.
Instead, Build a Skyscraper
Perhaps it’s not the most elegant analogy, but a sustainably-designed feature is kind of like a skyscraper (work with me). It is built with the aim of staying in-tact even if even one of its many levels has an issue.
In real-world terms, think of it as a navigation menu that doesn’t get overwhelmed when a new item is added. Or a column that doesn’t overrun its boundaries because it contains an extra sentence or two more than you anticipated.
That’s the essence of resiliency. It’s the practice of considering how a feature may be used (or abused). It’s realizing that there may be some uses you can’t anticipate. Then, it’s a matter of designing and building in a way that can withstand just about any scenario.
Of course, that doesn’t mean something is completely bulletproof. But it does eliminate the most likely breaking points. This allows a website to flourish long after its launch.
The Challenges
This all sounds wonderful, right? We work hard to create something that doesn’t wilt under pressure. But, like most things, it’s easier said than done.
There are many challenges involved in the process. The first comes in the form of having an eye for what will work and what won’t. The second is when a client asks for something that isn’t really sustainable. Let’s tackle them, one at a time:
Determining What Is Resilient
One of the best ways to determine what is and isn’t resilient in your designs is experimentation. You design and build something in the best way you know how, test it, then see how it plays out over time. The experience can prove invaluable as you move on to new projects.
Beyond experience alone, another way to figure things out is by using the house of cards analogy mentioned earlier. If something you create is so heavily-dependent on one aspect – a CSS class being in a specific place, an empty div or some other lynchpin – it’s probably not resilient.
The great aspect of this is that mistakes serve as learning opportunities. The more you learn, the better you’ll become at building resiliency into your projects.
Educating Clients
Clients often come to us with ambitious plans. This is especially so when your client is a designer who provides you with a mockup to build off of. They might send you a Photoshop, Sketch or XD file that includes some challenging aspects. Or, a client may see a visually-appealing feature on another website and ask you to replicate it.
It’s a tough situation. These items may be possible with some CSS magic. You might even get it to work in all the major browsers (IE included!) – but at what cost?
Well, when your client makes a change a few months later, the feature that took you weeks of testing to get just right breaks like a twig.
Sometimes, part of the process of implementing a resilient feature is convincing clients of its value. Maybe something doesn’t look exactly like that cool feature from the other site, but will be easier (thus, cheaper) to maintain down the road.
Resiliency Starts from Scratch
Mocking up a website can be a fun experience. It’s a place to let your creativity loose and (hopefully) impress your clients with the results.
It’s also a time when we as designers can get ourselves into trouble. Ambition in design is often a positive, but it can also lead to that proverbial house of cards. Trying to get too cute with an element may pin you into a corner when it’s time to build.
That’s why it’s important to think about resiliency from the moment you open up your design app. Consider the consequences of each design decision you make. Ask yourself what will happen if an element doesn’t contain that exact amount of characters or is viewed on a small screen.
Take care of those concerns from the very beginning. It may just save you from receiving a message from a panicked client that the layout is broken or other assorted chaos. That alone makes it worth the effort.
The post The Case for Building Resiliency into Every Website appeared first on Speckyboy Design Magazine.
Package:
Summary:
Output form validation JavaScript from a INI file
Groups:
Author:
Description:
This class can output form validation JavaScript from a INI file...
Read more at https://www.phpclasses.org/package/11723-PHP-Output-form-validation-JavaScript-from-a-INI-file.html#2020-07-19-09:42:52
