Author: Dac Chartrand

eXtreme Go Horse (XGH) Process

eXtreme Go Horse (XGH) Process

1. I think therefore it’s not XGH.

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.

2. There are 3 ways of solving a problem: the right way, the wrong way, and the XGH way.

The XGH way is exactly like the first two but faster. XGH is faster than any development process you know (see Axiom 14).

3. You’ll always need to do more and more XGH.

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.

4. XGH is completely reactive.

Errors only come to exist when they appear.

5. In XGH anything goes.

It solves the problem? It compiled? You commit and don’t think about it anymore.

6. Always commit what you code.

If things go wrong your part will always be correct… and your colleagues will be the ones dealing with the problems.

7. XGH never misses a deadline.

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.)

8. Be ready to jump off when the boat starts sinking. Or blame someone else.

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.

9. Be authentic. XGH doesn’t follow patterns.

Write code as you may want. If it solves the problem you must commit and forget about it.

10. There’s no refactoring just rework.

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)

11. XGH is anarchic.

There’s no need for a project manager. There’s no owner and everyone does whatever they want when the problems and requirements appear.

12. Always believe in improvement promises.

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).

13. XGH is absolute.

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)

14. XGH is not a fad.

XP, Scrum, Lean? Those are just trends. XGH developers don’t follow temporary trends. XGH will always be used by those who despise quality.

15. XGH is not always WOP (Workaround-oriented programming).

Many WOP require smart thinking. XGH requires no thinking (see Axiom 1).

16. Don’t try to row against the tide.

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.

17. XGH is not dangerous until you see some order in it.

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.

18. XGH is your bro. But it’s vengeful.

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.

19. If it’s working don’t bother.

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.

20. Tests are for wimps.

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.

21. Get used to that ‘living on the edge’ feeling.

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!

22. The problem is only yours when your name is in the code comments.

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
Source: http://www.gohorseprocess.com.br/

SCRUM Open Assessments

“The way to make a million dollars is to start a religion software 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!

Developer Open
100% of my SCRUM – up to you true star.

Point:

Counterpoint:

PHP Configuration Files Rant

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.

I know some of you are thinking “Well that’s dumb. I wrote a game in PHP and the webpage isn’t reloading every time the user clicks…” but break that down: you wrote PHP which renders something the user is experiencing in a web-browser (C++) that may or may not be making Ajaxy calls back to the server (JavaScript) and PHP’s role in this solution is always to start-up, process data, return data, then exit.

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.

JSON, a “text only” and “language independent” data-interchange format, is currently the cool kid on the block, but from the perspective of JavaScript?

var json = { "this": "is", "valid": "javascript" };

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!

No.

But caching! But Transpiling!

No.

But I like coding parsers!

Cool! Use your powers for docs and data, not PHP configs.

But I secretly want to be a JavaScript, Python, Ruby, C#, Java or anything but a PHP developer!

Uhhh, OK?

[1] Unless you are storing your PHP configs in Apache or Nginx as ENV variables. Then to you madam or sir, I bow down.

Profile WordPress from the Command Line Using Blackfire.io and WP-CLI

Last week I needed a way to use Blackfire.io to profile a POST action in the WordPress administration panel.

I thought Blackfire.io would be able to handle POST the way Xdebug does: Generate a different cachegrind file for every PHP invocation; but alas, Blackfire.io currently only does static webpages, command line, or API calls. In theory I could have used “Copy-As-cURL in your Browser” (and believe me I tried) but in practice the WordPress admin is stateless (no $_SESSION), uses check_admin_referer() all over, making whatever POST action I was copying as cURL useless.

My solution was the following hack:

cd /path/to/wordpress
blackfire run wp eval-file --url=http://pressbooks.dev/helloworld/ test.php

Where `wp` is WP-CLI, `eval-file` loads and executes a PHP file after loading WordPress, `–url=` is the the current site I want to profile on a WordPress multi-site install, and `test.php` is a script containing only the functionality I want to profile.

The profiler data gave some bogus results (Ie. a lot of WP-CLI bootstrapping gets flagged as slow) but at least this was better than nothing.

In the future, it would be great if Blackfire Companion had some sort of option to profile “the next action,” or to “start profiler on submit,” or something other than reloading the current page… Ping SensioLabs?

Making and Doing in Kamogawa, Japan

Hackerfarm is a place is located in rural Japan, about two hours east of Tokyo on the Boso peninsula. It’s a cluster of buildings, a lot of shared tools, and a beautiful country setting […] a collection of Japanese and foreign tech hackers who’ve escaped from city life. We’re working together on projects, making life richer for ourselves and for the community who have adopted us. »

More info:

Forbidden File Names on Windows 10

When I switched from Linux/OSX  to Windows 10, I encountered problems with “disappearing files.”

First time it happened:

I have a web application with a directory  named “aux.” When copying over the project from Linux to Windows this folder and its contents silently disappear.

Second time it happened:

Pulling the textmate.ruby bundle from GitHub:

$ git clone git@github.com:textmate/ruby.tmbundle.git
Cloning into 'ruby.tmbundle'...
remote: Counting objects: 4012, done.
remote: Total 4012 (delta 0), reused 0 (delta 0), pack-reused 4012
Receiving objects: 100% (4012/4012), 1001.74 KiB | 0 bytes/s, done.
Resolving deltas: 100% (2061/2061), done.
Checking connectivity... done.
error: unable to create file Commands/@variable ||= memoized.tmCommand (Invalid argument)
error: unable to create file Commands/Enclose in * (RDoc comments).tmCommand (Invalid argument)
error: unable to create file Macros/class .. < DelegateClass .. initialize .. end (class).plist (Invalid argument)
error: unable to create file Macros/each_char { |chr| .. } (eac).plist (Invalid argument)
error: unable to create file Macros/each_cons(..) { |group| .. } (eac).plist (Invalid argument)
error: unable to create file Macros/each_slice(..) { |group| .. } (eas).plist (Invalid argument)
// ... snip ...

Argh…

List of reserved file names on Windows 10:

The following are (case insensitive) reserved names which cannot be assigned to a directory or file in Windows 10 :

  • CON
  • PRN
  • AUX
  • NUL
  • COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM0
  • LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT0

List of invalid file characters on Windows 10:

The following are special characters which cannot be assigned to a directory or file in Windows 10 :

  • < (less than)
  • > (greater than)
  • : (colon)
  • “ (double quote)
  • / (forward slash)
  • \ (backslash)
  • | (vertical bar or pipe)
  • ? (question mark)
  • * (asterisk)

Sources:

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx

Get cwRsync Working With Vagrant On Windows 10

Getting cwRsync to work with Vagrant on Windows 10 is a pain.

This tutorial is for people who have:

Reading comprehension 101:

cwRsync is a standalone version of rsync for Windows that doesn’t require Cygwin to be installed. I don’t have Cygwin installed because Git For Windows includes Git Bash and this is “good enough.” With a regular standalone cwRsync installation Cygwin will never be in the PATH and Vagrant will never add the required /cygdrive prefix.

Howto fix:

Add C:Program Files (x86)cwRsync (or wherever you installed) to your path. To avoid problems make sure this string is placed before C:Program FilesGitcmd and/or C:Program FilesGitmingw64bin;C:Program FilesGitusrbin

Add cwRsync to your path.
Add “C:Program Files (x86)cwRsync” to your path.

Add the following system variable: CYGWIN = nodosfilewarning

CYGWIN = nodosfilewarning
Add “CYGWIN = nodosfilewarning” as a system variable.

Edit (hack!)C:HashiCorpVagrantembeddedgemsgemsvagrant-1.7.4pluginssynced_foldersrsynchelper.rb

Change line ~43 from:

hostpath = Vagrant::Util::Platform.cygwin_path(hostpath)

To:

hostpath = "/cygdrive" + Vagrant::Util::Platform.cygwin_path(hostpath)
Edit rsynchelper.rb
Edit Vagrant’s rsynchelper.rb file

Restart your shells to apply changes. Fiddle with your Vagrantfile. Tada!

Troubleshooting:

Git for Windows is based on MinGw. cwRsync is based on Cygwin. You cannot run Vagrant & cwRsync from Git Bash because cwRsync includes it’s own incompatible SSH binary. If you try you will get the following error:

rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receive r=3.1.0]

Instead, when launching Vagrant use Microsoft PowerShell.

Sources:

[1] http://auxmem.com/2010/03/17/how-to-squelch-the-cygwin-dos-path-warning/
[2] https://github.com/mitchellh/vagrant/issues/3230
[3] https://github.com/mitchellh/vagrant/issues/4586