Development Archives - Page 2 of 3

Fixing gulp-include error of “no files found matching…” when the file exists

In using gulp to include files inline I ran into a bit of an error. gulp-include kept throwing the following error:

WARN: gulp-include – no files found matching [file_path_here]

These types of errors drive me crazy. The file was exactly where it was supposed to be. I checked it several times. What gives?! Turns out, gulp-include feels that finishing the include line with a semicolon is a deadly sin.

// remove the ending semicolon from include #include "lower_third_module"

module.jsx

view raw

Changing all includes to remove the semicolon did the trick. Here’s the gulp file for reference.

const gulp = require('gulp'); const replace = require('gulp-replace'); const include = require('gulp-include'); gulp.task("myTask", function() { gulp.src("src/lower_third_script.jsx") .pipe(replace("#include", "//=include")) .pipe(include()) .on('error', console.log) .pipe(gulp.dest("dist")); });

module.jsx

view raw

If you found this article, hopefully it will help you. Happy typing.

Getting Bootstrap, jQuery, Laravel-Mix and Electron to Play Together

While testing out Electron I wanted to begin building something with Bootstrap (my favorite “get-it-done” CSS framework). Since Electron requires build steps I’m going to use Laravel-Mix to handle getting Bootstrap 4, jQuery and Electron to work together.

The biggest challenge was running down a Bootstrap error when trying to compile jquery.min.js, bootstrap.min.js and tether.min.js into a single vendors.js file:

Uncaught Error: Bootstrap’s JavaScript requires jQuery. jQuery must be included before Bootstrap’s JavaScript.

Turns out, jQuery, when compiled is a module and not attached to the browser “window.” This means that jQuery or $ calls don’t resolve because window.jQuery or window.$ do not exist.

I got it all sorted out by pulling jQuery out of vendors.js and adding a require in the head on page. The resulting head of my Electron’s index.html looks like so (I have my html in a single folder in my electron project):

You may see an error here but don’t worry. In Electron (at least in their starter samples) the final script tag is below the closing body tag.

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Electron Thingie</title> <link rel="stylesheet" href="../dist/app.css"> <script> window.$ = window.jQuery = require('../node_modules/jquery/dist/jquery.min.js') </script> <script src="../dist/vendors.js"></script> <script src="../dist/app.js"></script> </head> <body>  </body> <script> // You can also require other files to run in this process require('../renderer.js') </script> </html>

index.html

view raw

You may see an error here but don’t worry. In Electron (at least in their starter samples) the final script tag is below the closing body tag.

If you’re interested, my package.json looks like so:

Dropped in Bootstrap, jQuery, Laravel-Mix and Electron. Also add a few scripts to speed up development.

{ "name": "electron-starter", "version": "1.0.0", "description": "", "main": "main.js", "scripts": { "start": "electron .", "webpack": "cross-env NODE_ENV=development webpack --progress --hide-modules", "dev": "cross-env NODE_ENV=development webpack --watch --progress --hide-modules", "hmr": "cross-env NODE_ENV=development webpack-dev-server --inline --hot", "production": "cross-env NODE_ENV=production webpack --progress --hide-modules", "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC", "devDependencies": { "bootstrap": "^4.0.0-alpha.6", "jquery": "^3.1.1", "laravel-mix": "^0.3.0", "electron": "^1.4.1" } }

package.json

view raw

And my build steps are insanely simple thanks to Laravel-Mix:

let mix = require('laravel-mix').mix; mix.combine([ 'node_modules/tether/dist/js/tether.js', 'node_modules/bootstrap/dist/js/bootstrap.js' ], 'dist/vendors.js'); mix.js('src/app.js', 'dist/'); mix.sass('src/app.scss', 'dist/');

webpack.mix.js

view raw

You’ll want to follow Laravel-Mix’s installation docs to get mix in place once you install the dependency.

Creating and Destroying Javascript Timeouts on the Fly

In Javascript, sometimes you just have to wait a few millisecond before you perform a task. A few examples

Assets need just a small window of time to render on screen
A button opens an overlay window and you want to close it after a set amount of time.
Delay an element animating in while you perform some other on page tasks.

All good things, all good things. Sometimes you may need to kill the delayed event after it was create but before it was performed. Let’s say you want a button to display something on screen and fade out after 5 seconds IF the user doesn’t close the element first.

var closeAThing = setTimeout(function() { console.log('remove thing automatically from screen'); }, 5000); $('.btn-close').click(function(evt) { evt.preventDefault(); console.log('remove the thing manually'); clearTimeout(closeAThing); });

view raw

Not to bad. But these variables are stored in a global scope and, every time you create one, you’re increasing the chance of a name collision unless you are careful with your variable conventions. So, to get around all this, here’s what I did. Maybe you’ll find it useful.

/* * ############################################### * Initialize Variables * ############################################### */ var pageTimeouts = {}; /* * ############################################### * Functions * ############################################### */ // set timeouts by name function createTimeout(name, func, time) { destroyTimeout(name); pageTimeouts[name] = setTimeout(func, time); } // destroy a timeout by name function destroyTimeout(name) { if (pageTimeouts.hasOwnProperty(name)) { clearTimeout(pageTimeouts[name]); } }

view raw

Why is this better? For one, it stores all timeouts in a single global object. That is kinda handy. It also cleans up creation, destruction, and checks if there is timeout of the same name and clears it before creating another. With this method, now you can create and destroy timeouts on the fly like so…

$('a.btn').on('click', function(evt) { evt.preventDefault(); $('.alert').addClass('animated bounceIn'); createTimeout('alert', function() { $('.alert').attr('class', ''); }, 5000); }); $('.alert a.close').on('click', function(evt) { evt.preventDefault(); $('.alert').attr('class', ''); destroyTimeout('alert'); });

view raw

I think it is pretty nifty. Hope it helps.

Unit Testing with a real Laravel UploadedFile object

I’ve tried, off and on, to unit test file upload objects in various Laravel projects with no real success. I don’t want to mock it and I don’t want to acceptance test a form. It doesn’t exist yet. I want a real file to so I can make calls over it to make sure I get all the data out I need. That I can detect an image, manipulate it using various packages, see the results and tweak till I’m happy and know that it is working when it goes into the app. In short, I’m TDD’ing the API of an object. If that makes sense.

In any case, after much Googling, testing, documentation look up and reading code I figured it out. Hopefully it helps someone else too.

Here’s the code and a bit of explaination…

/* Get byte size of file by doing the following at bash du -b FILENAMEHERE.JPG */ $file = \Illuminate\Http\UploadedFile::createFromBase( (new Symfony\Component\HttpFoundation\File\UploadedFile( __DIR__ . '/files/img_test_file.jpg', 'img_test_file.jpg', 'image/jpeg', 1993588, null, true )) );

view raw

When a file is uploaded to Laravel, a Symfony component creates a UploadedFile object form the $_FILE global. This object changes hands several times and ends up being converted to Laravel’s UploadedFile object. Then it is on to being dropped into the Request object that you can pick up in controllers and such.

What this code does is manually create the Symfony object and then manually converts that over to Laravel’s UploadedFile object. Fun. The arguments you see in the Symfony object instantiation are…

path to the file on disk. I stored it in a folder named “files” in the same directory as the test.
file name.
mime type.
size of the file in bytes.
how I feel inside. Actually it is number of errors. Same thing.
boolean confirming that this is being used for testing.

I hope this makes someones day. I almost laid a golden egg when this emerged from my night of profanity.

Happy coding.

Gnaryly Code – Converting One Bit of Data to Another

I had to convert one set of data to another… and it produced some very gnarly code. So what should we do with code like this?

The Dets

I have a Model called “Customization” which stores details that users provide in order to customize a product. Once that product is paid for and ready to go, the Customization needs to be stored in another model called “Process” in preparation for some time consuming processes behind the scenes.

This conversion from Customization to Process requires knowledge of the the customization, the Product that was customized and all its various relationships, and the format that all this information needs to be reworked into before being saved by the Process model.

Now What?

I could just give the Process model the logic to convert a Customization to a Process but that would have junked up the model, would require that model to know about many other models… quickly turning a maintainable project into something strung together and dependent on each other. Like House of Cards but with far less Spacey.

The Conclusion

I created an adapter class called CustomizationToProcessAdapter, pass it the info it needs, do all the ugly stuff away from prying eyes, and then pass the results back to be saved to Process.

Beautify. Well the code isn’t beautiful… it is quite ugly. But it is contained in something that can be tested and refactored all by itself without breaking anything.