Month: February 2017

In this episode, we’ll learn how to minify our JavaScript with Webpack and Uglify. However, in the process, we’ll also need to review environments. Often, you’ll want to use one set of configuration for development, and another set for production. I’ll show you how.
Source: Laracasts

Even in this day-and-age of readily available APIs and RSS/Atom feeds, many
sites offer none of them. How do you get at the data in those cases? Through the
ancient internet art of screen scraping.

The problem then becomes: how do you get at the data you need in a pile of HTML
soup? You could use regular expressions or any of the various string functions
in PHP. All of these are easily subject to error, though, and often require some
convoluted code to get at the data of interest.

Alternately, you could treat the HTML as XML, and use the DOM
extension, which is typically built-in to PHP. Doing so,
however, requires more than a passing familiarity withXPath, which is something of a black art.

If you use JavaScript libraries or write CSS fairly often, you may be familiar
with CSS selectors, which allow you to target either specific nodes or groups of
nodes within an HTML document. These are generally rather intuitive:

The above queries for ul.bs-sidenav li a — in other words, all links
within list items of the sidenav unordered list.

When you execute() a query, you are returned a ZendDomNodeList instance,
which decorates a DOMNodeList in order to
provide features such as Countable, and access to the original query and
document. In the example above, we count() the results, and then loop over them.

Each item in the list is a DOMNode, giving you
access to any attributes, the text content, and any child elements. In our
case, we access the href attribute (the link target), and report the text
content (the link text).

Other uses

Another use case is for testing. When you have classes that return HTML, or if
you want to execute requests and test the generated output, you often don’t want
to test exact contents, but rather look for specific data or fragments within
the document.

We provide these capabilities for zend-mvc
applications via the zend-test component,
which provides a number of CSS selector assertions
for use in querying the content returned in your MVC responses. Having these
capabilities allows testing for dynamic content as well as static content,
providing a number of vectors for ensuring application quality.

Start scraping!

While this post was rather brief, we hope you can appreciate the powerful
capabilities of this component! We have used this functionality in a variety of
ways, from testing applications to creating feeds based on content differences
in web pages, to finding and retrieving image URIs from pages.

Now that you’re a bit more comfortable with the concept of loaders, let’s figure out how to write our JavaScript in ES2015, and then apply a babel-loader to compile everything down to vanilla JavaScript that any browser can understand.
Source: Laracasts

Let’s move on and review Webpack loaders. Loaders allow us to transform and preprocess any number of file types. Maybe you’d like to require Sass files, or compile ES2015 with Babel, or even inject CSS into the browser’s head tag. Let’s review the process of requiring CSS in this episode.
Source: Laracasts

We live in an uber-connected world. I can’t tell you how many times I’ve complained about shoddy Wi-Fi or the fact that Twitter is down. As much as I love the connection provided by the web and various technologies, somewhere along the way we became terrified of being unavailable. We have to check email maniacally, so we don’t keep our senders waiting. Our cell phone alerts and Slack notifications practically dictate our schedules.

Do a quick Google search of “being unavailable, ” and you’ll get a slew of articles on emotional availability and tips on how to be more attractive in relationships. These articles bemoan to women how men don’t like their partners to be around all the time; they find their better halves more attractive when they are invested in their own lives and not constantly dependent on their man’s company.

As a woman, I find many of these articles completely ridiculous. I believe one should live their lives on their own terms and things will just work themselves out. There is, however, a positive correlation between being somewhat unavailable, especially in business. People fear that by putting away their electronics, the unavailability will reflect poorly on who they are as a worker.

Here’s a truth: being unavailable is good for both you and your company. Somewhere along the way—and I’ve spoken with disdain about this inane practice before—working a million hours a week became a status symbol. Being available all the time meant you worked hard and smart. Although it has been vehemently debunked time and time again, there are those out there that still believe they have to respond to emails while they’re showering to keep a leg up.

You don’t need to unplug completely to be unavailable. Many of the articles written about disconnecting are coming from people who don’t work closely with technology. They aren’t active on social media, and they don’t depend on Slack and other ChatOps to get their jobs done. Aside from the business aspect of being connected, a lot of us derive joy from hanging out on Twitter and consuming content.

In my personal experience, my iPhone is an extension of my day, not a complete productivity assassin. With that said, it has been proven that using a phone while performing another task leads to poorer performance. Studies have shown even just hearing alerts in the background is comparable to actively using the device. Is the solution to turn off the phone once you get into the house? Not for me.

We can all have our own definition of unplugging. For me, it’s turning off alerts now and then to focus on other things. In the case of my computer, it’s occasionally not bringing it with me to the couch when I’m watching TV. Unplugging is different for everybody. Remember you don’t have to go completely “off the grid” to glean the benefits of time away from the internet.

It’s great to unplug while still engaging in some tech. Don’t forget, however, to take some time away from the grind. Unplugging could just be not answering work emails or going on airplane mode. Whatever you choose, remember it is indeed okay to occasionally be unavailable.

Cloudflare has reported that under certain circumstances their edge servers were running past the end of a buffer and returning memory that contained private information such as HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data. And some of that data had been cached by search engines.

Tavis Ormandy from Google’s Project Zero first spotted the problem and reported this in the Chromium tracker:

It looked like that if an html page hosted behind cloudflare had a specific combination of unbalanced tags, the proxy would intersperse pages of uninitialized memory into the output (kinda like heartbleed, but cloudflare specific and worse for reasons I’ll explain later). My working theory was that this was related to their “ScrapeShield” feature which parses and obfuscates html – but because reverse proxies are shared between customers, it would affect all Cloudflare customers.

We fetched a few live samples, and we observed encryption keys, cookies, passwords, chunks of POST data and even HTTPS requests for other major cloudflare-hosted sites from other users. Once we understood what we were seeing and the implications, we immediately stopped and contacted cloudflare security.

Once Cloudflare was contacted they immediately jumped on the problem and reduced it down to their HTML parser that was used in email obfuscation, Server-side Excludes, and Automatic HTTPS Rewrites.

The issue is now fixed and rolled out to all customers and Cloudflare has a very detailed report on the background, the timeline of the fix, and how they fixed it. They also, worked with Google and other search engines directly to get to remove any cached HTTP responses.

If you’d like to see a list of sites running Cloudflare here is a list of some of the most popular domains.

UPDATE: Laravel News runs on Cloudflare and we received an email this morning saying this site was not affected. Here is a copy of the relevant information from that report:

In our review of these third party caches, we discovered exposed data on approximately 150 of Cloudflare’s customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.

Your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.

The term "module" used to scare me. What exactly are they? Well, as it turns out, the answer is very simple: they’re just files. Let’s experiment with importing and exporting modules, while taking a few moments to discuss CommonJS vs. ES2015 modules.
Source: Laracasts

While it’s neat that we can compile Webpack with a single command, in reality, you’ll almost always want to use a dedicated webpack.config.js file to configure your Webpack build. Let’s transition over in this episode.
Source: Laracasts

Laravel is a powerful and modern framework. It has tons of different features, which make our work faster and easier. But you can’t push everything into the single box. At one time or another, we’ve all been in need of something not implemented in the framework out of the box. So, you’re writing code by yourself; it works, and you are happy. Yep?

But what if you need the same functionality in another project? Will you write it again? Copy-paste it? Both solutions are bad because you’re solving the same problem again and again. And what about bugs? Imagine finding a bug in that code a few days later. Now you have to fix it in N places. Ufff, not fun!

A package can be a solution. Write your code once and use it in any number of projects. Maybe you found a bug, or want to make some changes? Do it just once in your package code and then pull required changes in all of your projects. Sounds good?

The First Step

Before diving into the work with your head, check Packagist first. It is possible someone has already solved your problem. If you can’t find an existing package, try to explore the question a little bit deeper. Maybe you’re not using the most accurate keywords in your search. Don’t be afraid to spend another 30 minutes; it could save you 30 days eventually.

Development

You’ve searched, but no luck and now you’re willing to create a new Laravel package. What are the next steps?

First of all, take a look at the Laravel documentation. The Package Development page is a great starting point. You’ll find out in most cases, the heart of your package would be a service provider. Here you can register event listeners, middleware, routes, translations, views, etc. Maybe your package has its own config file, maybe even its own database migrations. You have to describe all of that in your service provider. It is the connection point between your package and Laravel.

Your head is full of knowledge; you are creating new GitHub repo and starting to write code. Great! What tips can I give to you?

I think one of the most important things, when you’re writing a framework package is to make the package close to the framework. In everything: architecture, naming, code style, documentation, every aspect of it. It will be much easier for people to understand and use your package if it looks like the part of the framework. But, it’s not always easy to choose those best names for classes, methods, variables, etc. I really like Jeffrey Way’s method, which I learned at Laracasts. When you’re feeling a name isn’t very good, delete it and write it as you’d want it to be in a perfect world, then use it. Simple enough, but it works. Naming is not the easiest thing in programming, and there are a lot of good books about it.

I’ve received the following feedback from someone using my package: “Nice readme file! It’s really easy to read it, it feels like I’m reading one of the Laravel docs!” That was my victory!

If people feel your package is a natural part of the framework — you’re on the right path.

Testing

Package testing can be really tricky. And the first question I had, before even starting to write tests was this: how should I test it? Should I create a new instance of my Laravel project, install my package there, and write my tests? These were the real usage conditions of my package, but my tests would be located outside of the package, which is really bad.

Luckily, there is Testbench Component to solve that problem. It provides a way to test your package without a standalone Laravel install. You can easily register your package service provider, aliases, set up the database, load migrations, etc.

The great thing about open source is you can use cool GitHub integrations for free. They can help you in different ways.
My favorites are:

Documentation

Don’t be lazy; create a nice readme file. It can be really useful for you because you’re taking another look at your package in general. There have been so many times while writing a readme file that new ideas have come to me. And having a good readme allows others to be able to use your package as well. Isn’t it great to know your code is useful for someone?

I think a readme file is really important, and it should be as simple as possible. Use images, where possible. They are easier to understand. Write your documentation as close to Laravel Documentation as you can.

Release

Don’t forget to add your package to Packagist, so it will be available through Composer. That will make your package installation really easy, and make it searchable through Composer. Use keywords in your composer.json file. You can also set up GitHub Topics to make your package even more searchable.

Conclusion

Creating your own packages can make your code cleaner, preventing you from repeating yourself over and over in different projects. I’m not saying you have to extract everything into the packages, no. It’s all about the balance, like in coding. Should I extract that code into the separate method? Or, maybe even into the separate class? Remember those questions? I think “Should I extract that code into the separate package?” is something similar to these questions. It depends. Feel it, and make a decision according to your context and experience.

There are a lot of aspects, which are not covered in this short article, but I really hope it will be useful for someone. Please, contact me if you have any thoughts or questions.