Kevin Schroeder has a post to his site sharing some helpful tips for monitoring Magento jobs and crons to help provide a bit more information about the job and its current state.

About a month ago a client of mine was lamenting the fact that they didn’t have insight into what was going on with their cron jobs. So I did what any idiot would do and built out a service that does just that. It works with any Magento version, 1 or 2, system crons, and you can use an API to integrate it with your own system with a very minimal amount of work. I call it the 10n Job Health Vault. With Magento 1 or 2 you can have it set up and running in under 5 minutes (minus DI compilation time, of course).

The tool tracks the execution of the job and notifies you if something's wrong and it hasn't finished. This also means it can track the execution time and report back if it's slower than usual. You can find out more information about this Magento monitoring tool on its website.

On the Medium.com site today Laravel project lead and creator Taylor Otwell has posted about a feature coming in the 5.6 release of the Laravel framework: single server scheduling.

Today Laurence Ioannou, founder of the Laravel monitoring application Eyewitness.io, contributed a great new feature to Laravel 5.6 (February 2018 release): single server scheduling.

He illustrates the new feature by first defining a new "inspire" job, making it run hourly with the artisan command and not overlap with a previous execution. While this works with a simple server, it doesn't scale to multiple - that's where the "single server scheduling" comes in. The addition of this support provides a new onOneServer option that prevents the job from running elsewhere. It makes use of Redis or Memcache to store the information about which server it is running on so that will need to be enabled to use this feature.

On the Unnikked.ga site there's a tutorial posted by Nicola Malizia showing you how to schedule user-generated cron jobs in Laravel using the built-in job handling functionality.

While developing a personal project I was in the need to let user defines actions that run periodically.

My first thought was to use the Task Scheduling component of Laravel. The solution that I came up with is quite simple, yet effective.

He then walks through the process of setting up a "tasks" table where users can define their jobs and how to pull and execute them as a part of the Kernel.php configuration. He ends the post asking readers if there's another way they might go about this and still allow users to define their own jobs without having to write the code for each type.

Freek Van der Herten has a new post to his site showing you how to handle Stripe callbacks when integrating its webhook functionality into your application. True to form, he also created a Laravel package to make it even easier.

In the project I’m currently working on I had to integrate Stripe webhooks. Stripe has great documentation on how to handle webhooks, but it still took a fair amount of time to get the integration just right. My solution for handling webhooks is pretty generic and reusable by others. I decided to extract it to a package called laravel-stripe-webhooks, so nobody has to code this stuff up again. In this blogpost I’d like to share how the package works.

He then goes on to talk about the request validation that happens on the webhook callback and how the information can be reworked if something goes wrong. He then talks about the handling of valid requests either using a custom job or using events to trigger when a "source.chargable" event is fired.

There's an interesting article from Christian M. Mackeprang that tries to provide some definition to the term "full stack programmer" and what it really means to the job market.

Back around 2013, the term Full Stack developer started to come up in job descriptions and blog posts. Companies were realizing that hiring developers with expertise in only one language just wasn’t enough anymore. A web developer that can handle a variety of tasks and environments is considerably more useful, and was starting to become the norm.

[...] What is a full stack developer supposed to know, anyway? Job descriptions frequently mention combinations of frontend and backend technologies such as JavaScript and Node, PHP and jQuery, Angular and Spring, and many others. In reality there is a significant amount of information outside those realms that would improve someone’s ability to build a website, and gone are the days when you could stick with what you know and make a career out of a single technology.

He talks about the combinatorial explosion the number of possible technology combinations can cause and how the usefulness of specific posts/resources is dwindling because of it. He then talks about "hackers" as "antifragile programmers" being the ones that enjoy the exploration of the tools and systems and are not bothered by change. He also suggests that developers need good skills in time management and setting expectations to prevent too much "exploration time".

He finishes out the post sharing thoughts about redefining the roles we're actually looking for an the individuals we want to fill them. He offers pointers about gaining context around issues, understand tradeoffs and doing what other people don't like doing to make your way ahead.

The Scotch.io site has a tutorial posted showing you how to combine Laravel and the Twitter Streaming API to process tweets in real time inside your application.

This tutorial will show how to use the Twitter Streaming APIs to process tweets in real-time from a Laravel application. There are a variety of use cases for this: perhaps you want to auto-respond to mentions of your company, run a contest via Twitter, or create support tickets when users complain about your product. For this tutorial, we'll build a "featured tweets" widget to display approved tweets on our app's home page.

He starts with an overview of the tools and terms you'll need to know about for the tutorial and a few notes of things to watch out for. He then describes the overall structure of the application (an app just to show the tweets) and links to a repository for the impatient. He then breaks up the rest of the tutorial into several steps:

• Creating a new Laravel application and installing the Phirehose library
• Building a "process tweet" job and matching TwitterStream class to use Phirehose and dispatch the job
• Make the artisan command to connect to the API and the application you created
• Configure your queue driver and run the processing command
• Set up a "Tweet" model to connect the application and database table

He finishes the post showing how to make the ProcessTweet Job useful, set up some basic authentication and pass the currently processed tweets into the default "Welcome" view.

Recently Cal Evans took an informal survey of fellow Twitter users and asked them what they thought was most important to see in a job ad for a developer position. In this new post he shares some of the results and responses to the question (with a surprising range of answers).

In my book “Culture of Respect” I have a section on writing job ads that will attract developers. I am in the process of revising that chapter, so I thought I would ask the people who actually read the job ads what they look for. The results weren’t that surprising to me. Having read a lot of job ads though, I am guessing that the results will be surprising to some managers out there.

He's embedded the tweets themselves in the post (straight from the horse's mouth, so to speak). Responses touch on subjects like:

• salary requirements
• clear definition of duties
• less "buzz words"
• well-defined list of technologies they'll be working with

The results are interesting and a definite must read for anyone coming up with job postings for open developer roles in your company.

While the advice that Matt Stauffer gives in this new post to his site is more targeted towards people applying at his company, it's full of great tips for just about any job seeker looking to land a role in web development.

I just finished reading over 200 applications for our latest job posting, a Web Developer job at Tighten Co.. We still hire infrequently enough and are small enough that the two founders (Dan and me) and our operations manager (Dave) read every single application, which is hours upon hours for work before we even get to our initial phone screen.

Some applicants, and some tendencies among applicants, have stood out as best practices, but many more things have stood out as consistent turnoffs. So, I figured I'd share some with you here.

He includes helpful hints on topics like:

• actually reading the job description
• writing custom cover letters
• updating your site and resume to the latest information
• provide up to date code samples
• check spelling and grammar

He offers one other piece of advice that I think a lot of job seekers don't bother with: set yourself apart somehow. This may mean extra work on the application but it can yield very positive results. He ends the post with some extra tips he received as feedback on Twitter, asking hiring managers what they really want to hear from applicants.

Sherif Ramadan has a new post to his site today that tries to answer the question "what does a software developer really do?"

As a software engineer I have to learn to see things differently, because my job requires that I solve problems. Though not only is it important that I come up with a solution, but equally important that I can express the solution in code. [...] It is equally important to recognize that not all problems have technical solutions. Some problems are better solved by social solutions.

He talks about the influence that some of the major services have had on the social aspects of our lives and how they're mostly a "convenience to mankind". He suggests that the job of a software engineer has multiple aspects, and not just technical ones. They're required to see things differently, be able to understand the problem well and express the solution in a clear and practical set of code.

The engineer must figure out which problems are worth solving through technology, in order to save people time and money, and defer those which do not to more social means. Let humans do what they do best and computers do what they do best.

On DevShed.com today there's a new article posted looking at methods for running scheduled jobs based on responses to this forum post.

I have a webpage form that requires a date and time to be submitted. When it's submitted I need the back-end to run a script at the time and date specified. Have you ever needed to do something like this?

Some recommendations already posted include:

• The UNIX "at" command
• Setting up a queue system to manage the processes (using something similar to Gearman
• Setting up a cron job to handle the periodic execution of the script.