@MarkRedeman
- Event Sourcing (ES)
- Command Query Responsibility Segregation (CQRS)
- Hexagonal architecture
- TestDrivenDevelopment (TDD)
- Domain Driven Design (DDD)
- Behavior Driven Development (BDD)
;;; private/renamed.el -*- lexical-binding: t; -*- | |
;;;###autoload | |
(defun +renamed/find-in-dotfiles () | |
"Open a file somewhere in ~/.dotfiles via a fuzzy filename search." | |
(interactive) | |
(doom-project-find-file (expand-file-name "~/dotfiles"))) | |
;;;###autoload | |
(defun +renamed/browse-dotfiles () |
<?php | |
// Immutable | |
final class Committee | |
{ | |
private $name; | |
private $goal; | |
private $members = []; | |
public function __construct(string $name, string $goal, array $members) |
<?php | |
/* | |
* A bit of background: | |
* | |
* Because this is a project where one of the main goals for me is to learn new techniques, | |
* I want to apply event sourcing to this project. | |
* | |
* We're modelling a student association where we want to manage memberships of the association. | |
* Most members will finish their studies in about 4 - 6 years and if they do not stay active |
Mutation testing is a technique that measures the quality of a test suite and helps you write more robust code. This is done by making small changes (mutations) to our code, which will break our application, and ensuring that there is at least one test that no longer passes.
This talk introduces the concept of mutation testing. We show that by using mutation testing we can find bugs in code which has a 100% code coverage. We will look at a few open source projects and use the padraic/humbug package to analyze their Mutation Score Indicator. Lastly we look at some of the disadvantages of mutation testing, namely performance and false positives and how to overcome them.
%% make_counting_function: | |
function [g] = make_counting_function(f) | |
count = 0; | |
function [varargout] = counting_function(varargin) | |
if (nargin == 0) | |
varargout = {count}; | |
else | |
count = count + 1; | |
varargout = {f(varargin{:})}; |
In this blog post I talk about Laravel's Service Providers and about its life cycles.
In brief, a Laravel application is bootstrapped (started) whenever a webrequest hits index.php
in the public
folder, or when an artisan
command is executed. Tough both the index.php
and artisan
file work very similarly, I will only talk about index.php
.
When the index.php
file is called it registers the autoloader. After that Laravel's Application is initiated and stored in the $app
variable which is used to construct a kernel that manages the input and output of our app.
After handling the input by our $kernel
it returns a $response
object which is send back to our visitor.
Let's rewind a bit, there are four1 important things that are done in the index.php
:
Application
class is initiated and stored in $app
$app
's Service Container.<?php | |
// Use a value object to represent Hashed Values (for example passwords) | |
// this way we can deterine if a string has been hashed before or if it needs hashing | |
class HashedValue { | |
private $hash; | |
public function __construct($hash = '') | |
{ | |
$this->hash = $hash; |
<?php namespace Reconcept\Core\Commands; | |
use Illuminate\Foundation\Application; | |
use InvalidArgumentException; | |
class DefaultCommandBus implements CommandBus { | |
/** | |
* @var Application | |
*/ |
<?php | |
class AddStudentGradeToCourseCommand { | |
public $studentId; | |
public $courseId; | |
public $grade; | |
public function __construct($studentId, $courseId, $grade) | |
{ | |
$this->studentId = $studentId; |