Back to Roots

PHP was my first real programming language. And Laravel is built with PHP. I’ve always heard of Laravel, but never used it. I’ve watched many videos about how good it is, installed a sample application – and was sold.

I want to learn more – so I signed up for Laracasts. If you’re a web developer, suffering from JS Fatigue, and want to learn Laravel – Laracasts.com is like striking gold.

Top-notch tutorials and lessons. I, for one have signed up on many premium bootcamps and tutorial websites. So far, Laracasts is the best I’ve seen. Let me explain.

Talented Instructors – Jeffrey Way

Jeffrey Way, the main instructor, has a unique gift for making complex topics easy to understand. His explanations are clear and straightforward, making even the most daunting subjects feel manageable. He has a way of teaching – that reminds me of how elementary school was – but for a modern, experienced developer.

Plus, he presents everything in such an engaging way that you’re hooked from the first video. I especially like how he organizes his content – from inception to conception. Jeffrey Way is as good as it gets.

In addition, I’ve seen a couple of series on Inertia, React and APIs – and the instructors were also pretty good. Not the same style as Jeffrey – but good nonetheless.

Structured Learning Paths for Laravel and More

One of my favorite features is the structured learning paths. These pathways are like having a personal guide through the vast world of web development. They ensure you build a solid foundation before moving on to more advanced topics. This is incredibly helpful if you’re new to coding or trying to learn a new framework like Laravel.

There is also small bits of lessons called “Larabits“. These are quick how-to videos, that’s not necessarily tied to a learning path. Just fast paced watch and go type of tut.

Supportive Community

The community at Laracasts is fantastic. The forums are buzzing with activity and full of people ready to help out with any questions you might have about Laravel tutorials or other topics. It’s great to be part of a community where you can share knowledge and get support from fellow learners.

Plus, Jeffrey Way is actively involved, which adds a personal touch to the experience.

In addition, each video has a comments area – where you can post comments – and the community is also very responsive. This helps when you’re stuck in part of the video, commenting will get you “unstuck” real quick.

Diverse Range of Topics Beyond Laravel

While Laracasts is famous for its Laravel tutorials, it doesn’t stop there. The site offers in-depth tutorials on JavaScript, Vue, React, testing, and general web development practices. As mentioned above – the instructors and the way they teach the course is paramount. So the topics can vary – and you get the same high quality tutorial – which is a good deal.

So whether you’re looking to dive deep into a specific framework or broaden your overall skill set, Laracasts has you covered. I was even surprised to see GraphQL, CSS and Webpack in there – its not just backend stuff!

Final Thoughts

Laracasts.com is a must-have resource for anyone serious about web development, especially if you want to master Laravel tutorials. Its combination of excellent instructors that produce high-quality content. The strong community that you become part of – is truly indispensable. You get to learn everything about Laravel, but also other skills as well. In addition, the library is constantly updated, with new paths, technologies and lessons.

Whether you’re aiming to become a Laravel expert, improve your JavaScript skills, or just become a better developer overall, Laracasts is an investment you won’t regret.

The post Laracasts.com: a gold mine of content for Web Developers appeared first on Michael Soriano.

Such as this one that I found written by Obed Parliapano called A Visual Guide to React Mental Models.

Halfway through the article, I bookmarked and kept reading. Thought to myself, damn this is a really good explanation of React (as well as components, JSX and JavaScript itself). Not only with words, but with visual imagery as well. I agree with his approach of having “Mental Models” in trying to understand complicated things. React is one of those things. And yes, a mental model really helps.

The author asks to share the article and since I enjoyed it so much I’m going to do a step further and write about it. Be sure to check it out.

The post A really good explanation of the inner workings of React appeared first on Michael Soriano.

For those struggling with permissions in Ubuntu / Apache, continue reading below.

If you’re like us, you develop Web applications and deploy them on Linux servers (development or production environments), you might have wondered how to handle file permissions on the application files in a simple and fool-proof way.

Some facts

Developers operating on the server require specific file permissions on the application files to be able to read and write them (for obvious reasons).

The web server (Apache, nginx, Lighttpd, etc.) also requires specific file permissions on the application files to be able to read them, and for some files (but not all files), to be able to write them (like for instance, when uploading a file, or creating a thumbnail, etc.)

The problem

Both the web server and the developpers require file permissions on the same files to operate properly, but they might need different permissions on the same files.

Developers require the ability to read and write every file, while the web server might require only write permissions only on some files.

This constrained shared-resource problem can quickly become a nightmare for the person in charge of the server.

The user~group (flawed) solution

One common solution is to give developers the same user group as the web server (something like www-data), and then to juggle on with ownership on files

While this works in some ways, it’s flawed in others:

• concurrency problem: when a developer creates a file, the file is owned by the developer, and might not be readable (nor writable if needed) properly by the web server process (granted, one could use some ACL system on the FS, but who ever got this to work properly ?)
• impermeability problem: if you have several web applications running side-by-side on your web server, you’ll have to juggle a lot more with groups and sub-groups just to prevent Developer A to be able to see and modify Application B.
• stability problem over time, and accordingly with the principle of increase of entropy, file permissions will become a mess and perms related bugs will occur.

Our (awesome) solution

Wouldn’t it be great if a developer could read and write files of an application with its own unshared user / group, while allowing the web server to have it’s own and developer-unscrewable permissions on the files of the said application ?

Well yes, it would, and that’s exactly what bindfs is meant for.

With bindfs, developers access applications via dedicated filesystem mountpoints (placed in their home dir), acting as file-permission filters, presenting files like they’re owned by themselves, whereas the files are really owned by the web server user (like www-data).

Advantages:

• it solves the concurrency problem, as every user in the equation (every developers and the web server) sees the permissions that he requires to operate properly and safely;
• it solves the impermeability problem, as if you need one developer to access a particular application, you have to add a mountpoint in its home directory, but on the contrary, if the you need one developer to not access a particular application, you just have to not add such a mountpoint in it’s home directory.
• it solves the stability problem, as developers will never be able to change the file permissions set on the application files, as required by the web server to operate properly and safely.
• best of all, it’s simple to understand and to setup !

How to use this

For Ubuntu / Debian systems

In the next example, we assume that the developer user is devone, the web server user is www-data and the application is stored at /var/www/application1.

# Installing bindfs (just the first time)
root@netgusto $ apt-get update
root@netgusto $ apt-get -y install bindfs
# Creating the application mountpoint
root@netgusto $ mkdir -p /home/devone/websites/application1
root@netgusto $ chown -Rf devone:devone /home/devone/websites
root@netgusto $ chmod -Rf 770 /home/devone/websites

Then, edit the content of /etc/fstab and add this line (just one line, without line wraps):

bindfs#/var/www/application1 /home/devone/websites/application1 fuse force-user=devone,force-group=devone,create-for-user=www-data,create-for-group=www-data,create-with-perms=0770,chgrp-ignore,chown-ignore,chmod-ignore 0 0  

Save the file, and proceed with mounting application (will mount automatically at system load):

root@netgusto $ mount /home/devone/websites/application1

If your system yells about force-user or force-group not being defined:

• replace force-user by owner
• replace force-group by group

Testing the solution

Once the application is mounted, you can test it by creating a file in the application mountpoint using the devone account, and verifying the file perms:

# as root
root@netgusto $ su - devone
# as devone
devone@netgusto $ cd ~/websites/application1
devone@netgusto $ touch helloworld.txt
devone@netgusto $ ls -l helloworld.txt
-rwxrwx--- 1 devone devone 0 sept. 10 17:15 helloworld.txt
devone@netgusto $ exit
# as root again
root@netgusto $ cd /var/www/application1
root@netgusto $ ls -l helloworld.txt
-rwxrwx--- 1 www-data www-data 0 sept. 10 17:15 helloworld.txt

The file is owned by www-data:www-data whereas we created it as devone:devone ! It worked !

One more thing

If you want to prevent developers to access /var/www/application1 directly, you just have to execute this:

# Attribute the /var/www root dir to www-data:www-data
root@netgusto $ chown www-data:www-data /var/www
# Change the permissions so that only the web server can enter this dir
root@netgusto $ chmod 770 /var/www

Note that the web served directory /var/www/application1 has nothing to do with bindfs, so it should not impact at all your web server.

How cool is that ? Tell us what you think !

Here is where the original article ends. I would like to say thanks to Jérôme and this digital ocean article (which lead me to it)

The post Solving the web file permissions problem once and for all [Repost] appeared first on Michael Soriano.

Enter Redux. Redux is an application that is built mainly to handle state. Note that Redux can be used without React. It can be used alongside JavaScript applications that needs it.

By the way, I struggle with React and Redux. I couldn’t grasp working with the two technologies together. So I decided to take a step back – and learn just Redux. I took Mosh Hamedani’s course and here’s what I discovered.

Building Blocks

So for Redux to work, it needs these 3 building blocks 1) Actions, 2) Store and 3) Reducers.

1) Actions

This is a JavaScript object that describes the CRUD operations for your store. It also contains the “payload” – which is data that is going to change the store.

It needs a “type” property which describes the action. An example type will be when an item is inserted, so a good “type” would be “ITEM_ADDED”. There is also another property called “payload”, which is another object that contains the minimal information about what is getting updated or inserted or deleted.

Check out this example Action Object:

[
	{
		type : 'ITEM_ADDED',
		payload : {
			id : 30,
			name : 'coffee'
			desc : 'drink'
		}
	},
	{
		type : 'ITEM_DELETED',
		payload : {
			id : 25
		}
	},
	{
		type : 'ITEM_UPDATED',
		payload : {
			id : 30,
			desc : 'warm clothing'
		}
	},
]

You see how it contains only the minimal information in the payload. For example, when deleting an item, all you need is the ID.

So you create an action object each time you want to change the store. As mentioned, the action contains the type (what kind of change) and the payload (the actual changes) that you want.

But the Action alone doesn’t change the state. We’ll get to that.

Let’s move on the Store:

2) Store

This is the single source of truth. It’s also a JavaScript object – and it’s immutable. Meaning we can’t edit it directly. In order for us to edit it, we need to call its dispatch() method, and pass in the action.

A store can be as simple as this:

{
	User_data : {},
	Items : [],
	Categories : []
}

But before we can even create a store, we have to have a reducer. Let’s move on to that.

3) Reducers

So these are functions that mutate the store. Typically, you will have a reducer for each “slice” of the store. In the example store above, we should have 1 reducer for “User_data”, 1 reducer for “Items” and 1 reducer for “Categories“.  

Note that we don’t call the reducer directly. The store is responsible for calling the reducer, when we call the dispatch() method.

Here is a reducer for the “Items” in our store:  

function ItemReducer(state, action){
	switch(action.type){
		case "ITEM_ADDED":
			return [
				...state,
				{
					id :lastId + 1,
					name : action.payload.name,
					description : action.payload.desc
				}
			]
		case "ITEM_DELETED"
		...
	}
}

So think of the reducer as the blueprint on what should happen when you pass it an action. It looks at the action type, works with the action payload, and from this logic – returns a new state.

So we now have a general idea of Redux’s building blocks, it’s time to put them together. Here are the steps on what you should do:

Steps: 

There is a strict way of putting together a Redux application. This is done to keep the integrity of the store.

1. Design store
2. Define actions
3. Create a reducer
4. Create the store and pass in the reducer //by using createStore(reducer)

Once you have the store, you should have access to it’s functions such as:

• dispatch() // function to mutate the store
• getState() // function go get the state
• subscribe() // listen to changes in the store

Notice that there is only 1 method to mutate the store. It’s done this way to make things follow “pipeline” – all changes are done one way and one direction – to make things trackable and “subscribable”.

The post Just Redux – a quick and high-level overview appeared first on Michael Soriano.

So here are my goals for 2020:

Learn more AWS

I’ve picked up a few technologies the past year. Salesforce being one, I got better with React and Node. I also dabbled with Python a little bit, along with a couple of frameworks such as Flask and Django. This year, it has to be more AWS.

AWS is not new to me. As a matter of fact, we use AWS heavily at work. But AWS is a beast. There’s so much that I don’t know. And I see AWS getting bigger than ever.

So my goal is to learn more AWS. Maybe even move my sites to it (if cost makes sense). And I could use more formal training – we use Pluralsight at work and they have a greate AWS track. I plan to learn services such as Cognito, Lambda, API Gateways, EC2, Cloudformation etc.

Some Svelte

This one is more a “good to have”. I am not so excited about learning just another front end framework, but Svelte JS is not “just another” framework. You see, unlike React or Vue – Svelte has a lot less boilerplate. It does not use a virtual DOM – and its more of a compiler – than a framework.

So writing Svelte apps seems to be more “natural” JavaScript apps. And I like the sound of that.

Pickup Plant-based

This one is obviously not a technology-based goal. But it’s probably the most important one on the list. I haven’t been the healthiest as far as my food choices. Matter of fact, I’ve been constantly gaining weight through the years.

Switching to a plant based diet is something that I’ve always wanted to do. It’s not going to be an easy task – coming from someone who’s been eating meat forever. I may not totally convert to a 100 percent plant based (at least not right away). But if I can do 4-5 days a week of no meat – that’s a big achievement for me.

Write More Posts

I’ve always written about web development, but this time around, I think I would like to talk about other things.

I don’t plan to ramble about things just to have new content. But things that I think is worth writing. I plan to have more categories such as health, food (I happen to cook) and maybe some business ideas.

So there you go. It’s not an extensive list, but rather a short and “doable” one. I also would like to do this yearly, so expect to see another one same time next year.

Good Bye 2019, you’ve been good to me. Happy New Year to all.

The post Hello 2020! Plans, Goals and Forecasts appeared first on Michael Soriano.

I decided to publish it here. I’m hoping to not only that I meet all of them, but also set a good track record in the years to come.

Clean up Github repos

This one has long been overdue. I have a lot of repositories in Github that need cleaning up. By this I mean fixing issues, upgrading documentation, moving files and even – deleting some of them. When Github started – it was all the rage. I started moving even my old code there. I never had the chance to look back and clean them up. This year, this will be one my top priorities. A leaner set of Github repos.

Utilize GulpJS More

I’ve used a couple of tooling technologies in the past. But I really like Gulp because of its simplicity. I realize some of my plug ins could really use Gulp. As part of the cleaning up (above), utilizing Gulp is going to be part of it. Not only that it will make the plug in easier to use – but it will also benefit me by learning more of this nifty tool.

Adapt Bootstrap 4

Bootstrap is the world’s mostly used responsive framework. At the time of writing – version 4 is still on beta, but it’s already widely adopted by many developers. Version 4 has a lot of rewrite, deprecated classes and components. One of the biggest differences is Flexbox. It also introduces the use of ems and rems in CSS as a form of measurement.  So by using Bootstrap 4 – I will also expose myself to both technologies.

Finish WP-Vue Starter theme

This one is almost done. I am a big proponent of VueJS, which I’ve used in a couple of small projects. This time, I wanted to combine it with WordPress. As many of you know, WordPress REST API has long been part of the core. It opens up many possibilities – especially in making WordPress an application framework. JavaScript and SPA’s is already big in the development community – so integrating it with WordPress is a good choice. Again, this is going to be out real soon so stay tuned.

Learn OctoberCMS

I saw a tutorial on OctoberCMS. I really liked it. It looks like its going to be a popular CMS – especially for developers. I am making it one of my goals to use it on a small site. And maybe create a theme for it. I have a friend who needs a portfolio for his photography – so I think this is a good time to use OctoberCMS.
I’m keeping this list short so it’s more attainable. I might keep updating this post for my progress – if it becomes useful for myself or others.

The post Goals for 2018 appeared first on Michael Soriano.

Enabling Emmet in Visual Studio Code:

For VSCode, all you need is to activate this feature. Go to “File” > “Preferences” > “User Settings“. Under “Emmet“, you should see the following options:

// When enabled, emmet abbreviations are expanded when pressing TAB.
"emmet.triggerExpansionOnTab": true,
// Preferences used to modify behavior of some actions and resolvers of Emmet.
"emmet.preferences": {},
// Define profile for specified syntax or use your own profile with specific rules.
"emmet.syntaxProfiles": {},
// An array of languages where emmet abbreviations should not be expanded.
"emmet.excludeLanguages": [],

Simply add a syntaxProfile – which associates a language id + an Emmet profile. I believe for HTML it’s already turned on by default. But by enabling it in JavaScript (such as using React), you have to take additional steps:

Using Emmet in React:

So first, add the syntaxProfiles like so:

"emmet.syntaxProfiles": {
        "javascript": "html"
}

Now you have the ability to write HTML inside JavaScript files. But for React, there are certain words that reserved and you cannot use – such as “className” for “class”. You have to switch the language mode to “Javascript(React)”. Go to the bottom of the editor and click the language:
The “Select Language Mode” will prompt – look for “Javascript(React)”, if it’s not there, you need to install the extension: Babel ES6/ES7.

Now you can write HTML inside your components using Emmet. Remember, you can use this in any ES6 JavaScript files – not just React!

This is just the tip of what you can do with Emmet. Like I said, as soon as I used it – I became excited and wanted to share with the world!
Don’t forget to checkout the Emmet Cheat Sheet for a long list of what you can do with this tool. Happy Coding!

The post God Dangit Emmet! Where have you been all my life! appeared first on Michael Soriano.

• What is an isomorphic application?
• Isomorphic JavaScript: the Future of Web Apps​

Destkop applications? The IDE that I use to write code for our SharePoint apps (Atom) is written in guess what? JavaScript! Yes, even Microsoft is on board with JavaScript – their new IDE called Visual Studio Code is built using Electron – the same Javascript framework that Atom was built on.
Meteor.js is a powerful platform using the “MEAN” stack. Yes – Angular folks!
As for Databases? MongoDB (The “M” in MEAN) uses a type of data structure like “JSON” – which is JavaScript influenced.
What about WordPress? Yes even WordPress is focusing heavily on Javascript. The built in REST API is in the works and will bring in a whole mass of possibilities for JavaScript Developers. Watch Matt Mullenweg’s State of the Word 2015 speech where he emphasized loudly “Learn JavaScript”.
React is a JS library that let’s you write web components for dynamic applications. Components that you build all inside JavaScript (without templating or string concat).

So where am I heading with all of this?
The more I write JavaScript, the more I’m realizing how powerful this misunderstood language is. Lambdas, closures, higher order functions, prototypes – many concepts that are still tough to grasp – but really worth learning.
JavaScript is now the language of my choice. And I see it eat the web (if it hasn’t already). A quote from one of my favorite programmers: Eric Elliott:

Software is eating the world, the web is eating software, and JavaScript rules the web

Let me know your thoughts below.

The post JavaScript is eating the world of software… appeared first on Michael Soriano.

Compiling

Let’s tackle the first drawback: compiling less. Yes it’s a pain in the butt having to write your code, then going to the command line to compile. Since I use Atom for my editor, there is a plugin called less-autocompile which compiles our less files each time you save.
First, start Atom, and download the package. Go to “File“, “Settings“, “Packages“.

Once installed, you can start writing your LESS code right away. Make sure you write a comment on the first line: “//out: styles.css” – so the plugin can know what and where to output your CSS file. Once you hit “Save“, you should see your new .css file created.

So how easy is that? No command line, no other software – just compile right in your editor. Note that you should check your IDE for a plugin that’s similar. I’m sure there are plenty out there.

Debugging

The second drawback is debugging. Let’s inspect our HTML and see the debugging problem that I was talking about previously.

You see that the rule referenced goes back to our .css file! We need it to look into our .less file!
Luckily, we have Sourcemaps to the rescue. Sourcemaps is a way to map compiled / minified code back to its original source. This is especially useful for debugging and tracing code.
Make sure in Chrome, that the “Enable CSS source maps” option is checked.

Now back to our Atom IDE, our plugin less-autompile also supports outputting sourcemaps on save. So back to the first line of comment in our .less file, add “sourcemap: true“. Now save the your .less file and a sourcemap file will be added.
One thing I noticed though that I had to manually add another comment in the bottom of my .less file: “/*# sourceMappingURL=styles.css.map */“. This is to tell Chrome Developer tools where our .map file is.
Now refresh the page that you’re inspecting and see the file it’s referencing to. Notice that its now pointing to our .less file! Problem solved.

In closing, knowing the right tools for doing your job is key to increased productivity. Web development is no different. Thanks to LESS, Atom and plugins such as less-autocompile, we are well on our way to CSS success.

The post Working with LESS, Atom and Chrome Developer Tools appeared first on Michael Soriano.