I’ve been hanging out in Kizugawa Japan since mid December.
Kizugawa is near Nara.
I’ve been hanging out in Kizugawa Japan since mid December.
Kizugawa is near Nara.
I have a Cannon PowerShot camera. When I take videos it records .MOV files.
Regrettably, the QuickTime installer doesn’t work on Windows 10.
One “recommended workaround” is to install the K-Lite Codec pack. When I tried to install it I was prompted by this crap:
This is the primary reason why the Windows software ecosystem sucks. Searching for straightforward solutions lands you on the worst snake oil and sleaze bag sites. They embed their garbage in “next next” dialogue hell.
Always pay attention when installing software because often, a Windows software installer includes optional installs, such as this MyStart toolbar which is essentially a Trojan horse.
PS: The K-Lite Codec pack did not solve my problem. I uninstalled and opted for QuickTime alternative instead.
While developing a plugin for WordPress I was having trouble linting CSS files in PHPStorm. One file in particular was giving hundreds of false positives for errors related to paths:
This bothered me. I wanted to fix the reported errors but the reporting was wrong. Most of the time there was nothing to fix. After much fiddling I discovered files under a folder marked as Resource Root can be referenced as relative:
Low and behold the errors became real! Oh crud, time to fix.
In your .travis.yml file, add:
before_install: - composer require phpunit/phpunit:4.8.* satooshi/php-coveralls:dev-master - composer install --dev script: - ./vendor/bin/phpunit --coverage-clover ./tests/logs/clover.xml after_script: - php vendor/bin/coveralls -v
before_install: Calls composer and installs PHPUnit 4.8.* + satooshi/php-coveralls.
script: Calls the installed version of PHPUnit and generates a clover.xml file in
./tests/logs/clover.xml. (This XML file will be used by PHP-Coveralls.)
after_script: Launches satooshi/php-coveralls in verbose mode.
Create a .coveralls.yml file that looks like:
coverage_clover: tests/logs/clover.xml json_path: tests/logs/coveralls-upload.json service_name: travis-ci
coverage_clover: Is the path to the PHPUnit generated
json_path: Is where to output a
json_filethat will be uploaded to the Coveralls API.
service_name: Use either
Add badges to your GitHub README.md file.
[![Build Status](https://travis-ci.org/NAMESPACE/REPO.svg?branch=master)](https://travis-ci.org/NAMESPACE/REPO) [![Coverage Status](https://coveralls.io/repos/NAMESPACE/REPO/badge.svg?branch=master&service=github)](https://coveralls.io/github/NAMESPACE/REPO?branch=master)
REPO to match your GitHub repo.
I’m going to Kizugawa, Kyoto in 20 days and this is the office i’ll be leaving behind:
In XGH you don’t think, you do the first thing that comes to your mind. There is no second option as the first one is faster.
The XGH way is exactly like the first two but faster. XGH is faster than any development process you know (see Axiom 14).
For every solved problem using XGH seven more problems are created. And all of them will be solved using XGH. Therefore XGH tends to the infinite.
Errors only come to exist when they appear.
It solves the problem? It compiled? You commit and don’t think about it anymore.
If things go wrong your part will always be correct… and your colleagues will be the ones dealing with the problems.
Schedules given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time (even if that means accessing the DB through some crazy script, breaking other parts of the software, etc.)
For people using XGH someday the boat sinks. As time passes the system grows into a bigger and bigger monster. You better have your resumé ready for when the thing comes down. Or have someone else to blame.
Write code as you may want. If it solves the problem you must commit and forget about it.
If things ever go wrong just use XGH to quickly solve the problem. Whenever the problem is too big and requires rewriting the whole software it’s time for you to jump off before the whole thing goes down. (see Axiom 8)
There’s no need for a project manager. There’s no owner and everyone does whatever they want when the problems and requirements appear.
Putting TODO comments in the code as a promise that the code will be improved later helps the XGH developer. He/She won’t feel guilt for the shit he/she did. Sure there won’t be no refactoring (see Axiom 10).
Delivery dates and costs are absolute things. Quality is relative. Never think about quality but instead think about the minimum time required to implement a solution. Actually, don’t think. Do! (See Axiom 1)
XP, Scrum, Lean? Those are just trends. XGH developers don’t follow temporary trends. XGH will always be used by those who despise quality.
Many WOP require smart thinking. XGH requires no thinking (see Axiom 1).
If your colleagues use XGH and you are the only sissy who wants to do things “the right way” then quit it! For any design pattern that you apply correctly your colleagues will generate ten times more rotten code using XGH.
This axiom is very complex but it says that an XGH project is always in chaos. Don’t try to put order into XGH (see Axiom 16). It’s useless and you’ll spend a lot of precious time. This will make things go down even faster. (see Axiom 8) Don’t try to manage XGH as it’s auto-sufficient (see Axiom 11) as it’s also chaos.
While you want it XGH will always be at your side. But be careful not to abandon him. If you start something using XGH and then turn to some trendy methodology you will be fucked up. XGH doesn’t allow refactoring (see Axiom 10) and your new sissy system will collapse. When that happens only XGH can save you.
Never ever change – or even think of questioning – working code. That’s a complete waste of time, even more so because refactoring doesn’t exist (see Axiom 10). Time is the engine behind XGH and quality is just a meaningless detail.
If you ever worked with XGH you better know what you’re doing. And if you know what you’re doing why test then? Tests are a waste of time. If it compiles it’s good.
Failure and success are the same thing. People normally think that a project can have greater chances of failing when using XGH but that’s just one way of seeing it. The project failed. You learned something with it? Then for you it was a success!
Never touch a class of code which you’re not the author. When a team member dies or stays away for too long the thing will go down. When that happens use Axiom 8.
File Under: Funny
Quebec is ~4 times bigger than Japan.
Quebec has 1 nuclear reactor. (and shutting it down will take 50 years and cost $1.8 billion dollars.)
Japan has 54 nuclear reactors.
“The way to make a million dollars is to start a
religionsoftware development methodology.”
What does it mean to be a SCRUM disciple when you are a lone freelancer working remotely? For me it means the knowledge you retain by practising SCRUM in an Agile work environment fades.
Doing these open exams once-in-a-while helps jog my memory:
…bet you can’t beat my scores!
“A startup is an organization formed to search for a repeatable and scalable business model.” -Steve Blank
If we agree with that definition then:
Cut & paste from Intro to Lean Startup
Let’s start with a joke. This GitHub repository:
“It’s funny ’cause it’s true” -Homer Simpson
Text configuration files (XML, Yaml, JSON, INI, …) work when the configuration is read once, the software persists in memory, and the application doesn’t exit until the user is done.
This is not what PHP does best. Sure PHP also reads the configuration file “once” but the fundamental difference is that PHP starts and exits dozens, maybe hundreds, of times for a single user using a single application.
The metaphorical equivalent would be relaunching World Of Warcraft every time time a user clicks on something.
For PHP to be the right tool for the right job, it has to be fast. Fast for developers to develop in *and* also fast for end users. (Hooray for PHP7!)
Some clever devs get around configuration performance problems by adding extra steps such as transpiling text into pure PHP before deploying, but do these complicated solutions really serve the PHP developer and the underlying philosophy of how we write code? When it comes to PHP there is a nuanced difference between “performance” and “fast.”
Let’s talk about JSON.
Wow. Talk about language independence. No reprocessing!
The equivalent in PHP:
$php = [ 'this' => 'is', 'valid' => 'php' ];
Tada! No overhead of having to validate, process, and convert to PHP. Is it uglier? Debatable.
To be clear: XML, Yaml, JSON, and friends are fine as documents or as data to be processed by PHP. This is totally normal and sometimes even useful. 😉 Barring that, any reasonable PHP developer must conclude that configuration files cannot be a bottleneck. Not a bottleneck for speed of delivering shippable code, nor a bottleneck for acceptable performance. When choosing anything other than native PHP for configuration you are making a trade-off. Is the trade off worth it? The answer is always no. 1
But the secretary needs to be able to edit the app config live on the server and PHP is too hard for him!
But caching! But Transpiling!
But I like coding parsers!
Cool! Use your powers for docs and data, not PHP configs.
 Unless you are storing your PHP configs in Apache or Nginx as ENV variables. Then to you madam or sir, I bow down.