Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
At Google I/O 2019, the host company announced plans to release the Local Home SDK. This new solution, which was recently launched as a developer preview, aims to reduce latency and improve reliability by allowing smart home device providers to run actions locally rather than in the cloud.
A web page isn't locked in stone just because it has rendered visually. Media assets, like images, can come in and cause the layout to shift based on their size, which typically isn't known in fluid layouts until they do render. Or fonts can load and reflow layout. Or XHRs can bring in more content to be placed onto the page. We're always doing what we can to prevent the layout from shifting around — that's what I mean by layout jank. It's awkward and nobody likes it. At best, it causes you to lose your place while reading; at worst, it can mean clicking on something you really didn't mean to.
While I was trying to wrap my head around the new Layout Instability API and chatting it out with friends, Eric Portis said something characteristically smart. Basically, layout jank is a problem and it's being fought on multiple fronts:
intrinsicsize as an HTML attribute and aspect-ratio as a CSS property. Both are designed for this fight, although they don't really have great browser support yet, requiring DIY aspect ratio boxes intead. Plus, ideas like this change to UA stylesheets to widen the effectiveness of aspect-ratio.overflow-anchor.The post The Fight Against Layout Jank appeared first on CSS-Tricks.
For years, the WordPress admin has become increasingly overloaded with admin notices. Some of them are giant, branded notices with their own particular designs that obstruct users’ activities in the admin.
The Theme Review Team is taking action to curb obtrusive notices that fall within its purview – those generated by themes hosted in the official directory. In the excitement of yesterday’s announcement about the long-term plan to make make all WordPress.org themes accessible, this small bit of good news regarding admin notices slipped through the cracks. The team ratified a proposal from TRT member Danny Cooper to require all themes to use WordPress’ admin_notices API.
All the notifications generated by a theme should use the admin_notices API and follow the core design pattern.
During this week’s the meeting, Cooper cited Storefront, WooCommerce’s flagship theme, as one example of a theme-generated notice that does not follow the core design pattern and is shown on every page.
Another example is this style of activation notice on the Noto theme from Pixelgrade:
The Futurio theme has also employed a similar style notice for getting started after activation:
In the past these notices have not been expressly forbidden, although they are generally frowned upon by those who want to keep the WordPress admin from being overtaken by large, branded notices and calls to action.
Another example of an obtrusive notice is Hestia’s popup that appears if you activate the theme but then navigate to “Add New” on the Themes screen to hunt for a different theme. Cooper said this particular popup is likely outside the remit of this guideline, but it demonstrates what lengths theme shops will go to in order to better market their themes.
There don’t seem to be any specific requirements that would restrict the use of branding within the admin notices as long as they follow the core design pattern. A visual example of this pattern is shown below.
The Sydney theme has an example of a branding-free notice that works within these guidelines:
This new requirement will affect many popular themes on WordPress.org and will likely be applied the next time existing themes go through the update review process. Cooper said that themes already known to be in violation of this guideline will be prompted by the TRT to change their notices as soon as possible or risk suspension.
“It’s especially important that themes on the ‘Popular’ tab adapt quickly as other theme developers use them as inspiration when implementing similar functions,” Cooper said.
If you’ve been looking for a way to add slots and controls to the Document panel in WordPress’ content editor, check out a new plugin released by 10up called Gutenberg SlotFill and Filter Demos.
SlotFill and Filters is a new take on the classic filters, actions, and
“SlotFill is a pattern for component extensibility, where a single Slot may be occupied by an indeterminate number of Fills elsewhere in the application,” Ryan Welcher said.
In the demo screenshot above, 10up was able to stick to the Classic UI conventions in the mobile app while displaying the same information in the Document panel of the new editor.
SlotFill initially started as a GitHub repo where Welcher collected his findings. The repo eventually turned into a library of examples and explanations for SlotFill and JavaScript based filters.
In January, Welcher submitted a pull request to the Gutenberg repo asking for SlotFill to be added to the document sidebar. His request received positive feedback and not only has SlotFill’s documentation been added to the WordPress Core Gutenberg Handbook, but the functionality is available in Gutenberg 6.1 and will be available in WordPress 5.3.
To learn more about SlotFill, check out Welcher’s release post or the Gutenberg SlotFill and Filter Demos plugin. Welcher is also doing a session at the JavaScript For WordPress Conference, on July 11-13, 2019, where he’ll showcase basic and real-world examples of SlotFill in use.
Cassidy and Marie are talking vulnerability: at work, in software, and IN work ON software. What does vulnerability in work look like? And how putting yourself out there can be a great way to help you grow.
9:32 Jetpack
@FeignClient(name = "service-provider")
public interface EchoService {
@RequestMapping(value = "/echo/{str}", method = RequestMethod.GET)
String echo(@PathVariable("str") String str);
}Sentinel is an open source circuit breaker. It can be part of Spring Cloud Alibaba or as an individual package.
Feign is a Java to HTTP client binder. It’s aiming to simplify the REST API process.
Games media service RAWG opens its API for developers. RAWG is the largest games database with over 300,000 of games, 2M of screenshots, 400K of reviews and ratings, and now you can access all of it and much more via the API.
Microsoft has announced new Azure SDKs that meet updated Azure SDK API standards. The new libraries Microsoft has released are for Azure Storage, Azure Cosmos DB, Azure Key Vault, and Azure Event Hubs. Microsoft has been working on a new set of API standards that will apply across Azure SDKs in an attempt to modernize its portfolio and make for easier integration with software both within Microsoft and externally.
When we talk about HA, normally people think about the failover mechanism. However, making the cluster available to messages is also considered HA. And to a certain extent, I think it is more important than just making the brokers available. After all, users can and will feel the impact of this availability.
Here is the scenario:
In this ultimate guide I will give you a simple step-by-step tutorial on installing Kafka Docker on Kubernetes. This post includes a complete video walk-through.
There has been a lot of interest lately about deploying Kafka to a Kubernetes cluster. If you are wanting to take the deep dive yourself then you found the right article. Now that we have Kafka Docker, deploying a Kafka cluster to Kubernetes is a snap.
Hello everyone. In this tutorial series, we will learn how to use Angular 8 and the Web API to create a simple fullstack web application from scratch.
4:32
Django is a very versatile framework, primarily used for developing web applications, but it is also widely used in creating mobile app backends and REST APIs, among other things. Here we will take a quick look at how to make these things possible using Django.
As you all probably know, REST stands for “Representational State Transfer.” Basically, what happens is that a user (or some software agent on one end) provides some input (or performs some activity) and the result of those inputs (or activities) are sent to the server side using a protocol that allows a request to be sent to the server (in most cases a HTTP protocol is used, but it doesn't need to be HTTP, as long as it can support a request/response scheme). The server, on receiving the request, makes appropriate changes to the state of the system (hence we call it “State Transfer”).
Every now and then, a debate flares up about the value of typed JavaScript. "Just write more tests!" yell some opponents. "Replace unit tests with types!" scream others. Both are right in some ways, and wrong in others. Twitter affords little room for nuance. But in the space of this article we can try to lay out a reasoned argument for how both can and should coexist.
It’s best to start at the end. What we really want out of all this meta-engineering at the end is correctness. I don’t mean the strict theoretical computer science definition of it, but a more general adherence of program behavior to its specification: We have an idea of how our program ought to work in our heads, and the process of programming organizes bits and bytes to make that idea into reality. Because we aren’t always precise about what we want, and because we’d like to have confidence that our program didn’t break when we made a change, we write types and tests on top of the raw code we already have to write just to make things work in the first place.
So, if we accept that correctness is what we want, and types and tests are just automated ways to get there, it would be great to have a visual model of how types and tests help us achieve correctness, and therefore understand where they overlap and where they complement each other.
If we imagine the entire infinite Turing-complete possible space of everything programs can ever possibly do — inclusive of failures — as a vast gray expanse, then what we want our program to do, our specification, is a very, very, very small subset of that possible space (the green diamond below, exaggerated in size for sake of showing something):
Our job in programming is to wrangle our program as close to the specification as possible (knowing, of course, we are imperfect, and our spec is constantly in motion, e.g. due to human error, new features or under-specified behavior; so we never quite manage to achieve exact overlap):
Note, again, that the boundaries of our program’s behavior also include planned and unplanned errors for the purposes of our discussion here. Our meaning of "correctness" includes planned errors, but does not include unplanned errors.
We write tests to ensure that our program fits our expectations, but have a number of choices of things to test:
The ideal tests are the orange dots in the diagram — they accurately test that our program does overlap the spec. In this visualization, we don’t really distinguish between types of tests, but you might imagine unit tests as really small dots, while integration/end-to-end tests are large dots. Either way, they are dots, because no one test fully describes every path through a program. (In fact, you can have 100% code coverage and still not test every path because of the combinatorial explosion!)
The blue dot in this diagram is a bad test. Sure, it tests that our program works, but it doesn’t actually pin it to the underlying spec (what we really want out of our program, at the end of the day). The moment we fix our program to align closer to spec, this test breaks, giving us a false positive.
The purple dot is a valuable test because it tests how we think our program should work and identifies an area where our program currently doesn’t. Leading with purple tests and fixing the program implementation accordingly is also known as Test-Driven Development.
The red test in this diagram is a rare test. Instead of normal (orange) tests that test "happy paths" (including planned error states), this is a test that expects and verifies that "unhappy paths" fail. If this test "passes" where it should "fail," that is a huge early warning sign that something went wrong — but it is basically impossible to write enough tests to cover the vast expanse of possible unhappy paths that exist outside of the green spec area. People rarely find value testing that things that shouldn't work don't work, so they don’t do it; but it can still be a helpful early warning sign when things go wrong.
Where tests are single points on the possibility space of what our program can do, types represent categories carving entire sections from the total possible space. We can visualize them as rectangles:
We pick a rectangle to contrast the diamond representing the program, because no type system alone can fully describe our program behavior using types alone. (To pick a trivial example of this, an id that should always be a positive integer is a number type, but the number type also accepts fractions and negative numbers. There is no way to restrict a number type to a specific range, beyond a very simple union of number literals.)
Types serve as a constraint on where our program can go as you code. If our program starts to exceed the specified boundaries of your program’s types, our type-checker (like TypeScript or Flow) will simply refuse to let us compile our program. This is nice, because in a dynamic language like JavaScript, it is very easy to accidentally create a crashing program that certainly wasn’t something you intended. The simplest value add is automated null checking. If foo has no method called bar, then calling foo.bar() will cause the all-too-familiar undefined is not a function runtime exception. If foo were typed at all, this could have been caught by the type-checker while writing, with specific attribution to the problematic line of code (with autocomplete as a concomitant benefit). This is something tests simply cannot do.
We might want to write strict types for our program as though we are trying to write the smallest possible rectangle that still fits our spec. However, this has a learning curve, because taking full advantage of type systems involves learning a whole new syntax and grammar of operators and generic type logic needed to model the full dynamic range of JavaScript. Handbooks and Cheatsheets help lower this learning curve, and more investment is needed here.
Fortunately, this adoption/learning curve doesn’t have to stop us. Since type-checking is an opt-in process with Flow and configurable strictness with TypeScript (with the ability to selectively ignore troublesome lines of code), we have our pick from a spectrum of type safety. We can even model this, too:
Larger rectangles, like the big red one in the chart above, represent a very permissive adoption of a type system on your codebase — for example, allowing implicitAny and fully relying on type inference to merely restrict our program from the worst of our coding.
Moderate strictness (like the medium-size green rectangle) could represent a more faithful typing, but with plenty of escape hatches, like using explicit instances of any all over the codebase and manual type assertions. Still, the possible surface area of valid programs that don’t match our spec is massively reduced even with this light typing work.
Maximum strictness, like the purple rectangle, keeps things so tight to our spec that it sometimes finds parts of your program that don’t fit (and these are often unplanned errors in your program behavior). Finding bugs in an existing program like this is a very common story from teams converting vanilla JavaScript codebases. However, getting maximum type safety out of our type-checker likely involves taking advantage of generic types and special operators designed to refine and narrow the possible space of types for each variable and function.
Notice that we don’t technically have to write our program first before writing the types. After all, we just want our types to closely model our spec, so really we can write our types first and then backfill the implementation later. In theory, this would be Type-Driven Development; in practice, few people actually develop this way since types intimately permeate and interleave with our actual program code.
What we are eventually building up to is an intuitive visualization of how both types and tests complement each other in guaranteeing our program’s correctness.
Our Tests assert that our program specifically performs as intended in select key paths (although there are certain other variations of tests as discussed above, the vast majority of tests do this). In the language of the visualization we have developed, they "pin" the dark green diamond of our program to the light green diamond of our spec. Any movement away by our program breaks these tests, which makes them squawk. This is excellent! Tests are also infinitely flexible and configurable for the most custom of use cases.
Our Types assert that our program doesn’t run away from us by disallowing possible failure modes beyond a boundary that we draw, hopefully as tightly as possible around our spec. In the language of our visualization, they "contain" the possible drift of our program away from our spec (as we are always imperfect, and every mistake we make adds additional failure behavior to our program). Types are also blunt, but powerful (because of type inference and editor tooling) tools that benefit from a strong community supplying types you don’t have to write from scratch.
In short:
Use them together based on their strengths, for best results!
If you’d like to read more about how Types and Tests intersect, Gary Bernhardt’s excellent talk on Boundaries and Kent C. Dodds’ Testing Trophy were significant influences in my thinking for this article.
The post Types or Tests: Why Not Both? appeared first on CSS-Tricks.
Gutenberg plugin users who update to version 6.1 should notice a considerable difference in how the UI reacts to block moving actions. This release brings in the animation experiments that Matías Ventura introduced in a post titled “Using Motion to Express Change.” The subtle animations add realistic motion to block changes, creation, removal, and reordering, creating a smoother transition between actions. It lends a bit of sophistication to what was previously an instant but more abrupt interaction.
Riad Benguella’s demo video shows the new animation for block reordering. When blocks are added or deleted, content moves around the screen more fluidly, with the surrounding blocks sliding into place. You can test it live and see it in action on the Gutenberg Playground, which is now hosted on GitHub Pages.
Version 6.1 also incorporates more experiments on the block-based widgets screen that is still in progress. A new widget blocks editor has been added to the Customizer under a panel labeled “Widget Blocks (Experimental).” At the moment, editing widgets in the Customizer in such a constricted space doesn’t seem to make much sense. It’s easy to get the controls jumbled up on top of each other. Live previews work but are much slower than the experience of using the post editor, and users may wonder why they can’t simply edit the content on the page where it appears. It’s important to remember that this is still an experiment.
The experimental widgets screen has also been updated to include the block inspector and a global inserter. This screen can be tested under the Gutenberg » Beta menu in the admin.
Gutenberg had taken a dip in performance in the previous two releases, but 6.1 recovers that with significant gains in typing performance. The latest version is 30% faster on long posts.
This update includes more than two dozen enhancements, fixes, and documentation improvements. Check out the 6.1 release post for a detailed list of all the changes. Better yet, take the latest Gutenberg features and experiments for a test drive and you’ll get a good sense of where the project is headed and what will be coming to WordPress core in the near future.
In today’s global marketplace, you need a web presence to survive, but that’s not all. If you want to set yourself apart, you absolutely need to create engaging content. Content marketing has been around for quite some time, but in a day and age where we grab our phones or tablets every time we need an answer to a question or curiosity, it’s even more useful than ever.
When you create useful, relevant content for your audience, they’ll come to think of you as an expert and thought leader in your field, and they’ll keep coming back to you whenever they need information in your area. This is a great start, but it’s not enough to convert your viewers and readers into customers on its own.
You may find yourself wondering whether you should use more probabilistic data structures in your code. The answer is, as always, it depends. If your data set is relatively small and you have the required memory available, keeping another copy of the data in an index might make sense. You’ll maintain 100% accuracy and get a fast execution time.
However, when the data set becomes sizeable, your current solution will soon turn into a slow memory hog as it stores an additional copy of the items or items’ identifiers. Therefore, when you deal with a large number of items, you might want to relax the requirement of 100% accuracy in order to gain speed and save memory space. In these instances, using the appropriate probabilistic data structure could work magic — supporting high accuracy, a predefined memory allowance and a time complexity that’s independent of your data set size.
A few times recently, I've been asked about retrospectives -- specifically how to keep them from becoming a gripe session. Here are a few things that I've found effective:
While we certainly want to talk about and address any issues, I like to talk about the positive things that have occurred during the last period before we delve into things we might want to change. I haven't yet been involved in a retrospective where the list of positive things wasn't long. This helps set the tone for the rest of the retrospective.
Positive Psychology is a growing area of interest for many professionals. Its focus is on improving a person’s wellbeing and their sense of personal happiness.
It started as a focus of development in the field of psychology by Dr. Martin Seligman. He made a call to arms to help arm people with the skills to live a more positive life, and for professionals in the field to help people move away from a focus on what’s going wrong to a focus on what’s going well.