A rare post from me these days. The above Apache error means that you have a duplicated “Listen 443” command somewhere.
Jump over to /etc/apache2/ and $ grep -r Listen .
You’ll find it, added automagically to a default vhosts file perhaps.
Like Highlander, there can only be one.
This comes across my radar every once-in-awhile. Here’s yet another recent article from the Independant which talks about caffeine and cognitive health.
I first came across this research all the way back in 2008 from this Slashdot post. According to a BBC article, regular doses of caffeine may actually help prevent dementia, as shown in experiments on rabbits.
And this is all well and good, but what I want to know is what is science doing to protect us from what are apparently marauding bands of demented super rabbits?
I think I need more coffee.
A friend of mine recently ran into a fairly common problem: Trouble with an offshore vendor. Bad offshore development can be a black hole for both time and money.
He pinged me for advice on how to evaluate if they could really do the job. Here are some questions I recommended that he pose to them:
And of course, ask for a list of references. Now, if you’re like me you will probably receive this list, verify that the companies / names are real via Google, LinkedIn, etc. and leave it at that. Don’t. Call at least two of the references and speak with them in detail. Ask them about the above questions.
And if you can swing it, travel out to the meet the company personally. Turn it into a vacation. Better a vacation than black hole purgatory.
If you’ve ever had to format a string of values in most languages then you’re certainly familiar with the ugly logical hoops you have to jump through just to get the formatting to look good.
Here’s a nice way to do it in Twig:
|
1 2 3 4 |
{% for phoneNumber in phoneNumbers if phoneNumber %} {{- loop.first ? 'Phones: ' : ', ' }} {{ phoneNumber -}} {% endfor %} |
So given a dirty array of phone numbers:
['123-4567', '', '321-7654']
the above snippet will strip empty values, chomp extraneous whitespace, and output:
Phones: 123-4567, 321-7654
Symfony 2.5 implemented handy multiple file upload support, e.g. input fields that look like this:
<input id="form_resumes" multiple="multiple" name="form[documents][]" required="required" type="file" />
Unfortunately there seem to be some problems in the Validator component. For example, it’s difficult to require at least one file. Likewise the All constraint doesn’t play nicely with validation groups. Here are a few workarounds.
To require at least one file but not more than three, use the Count constraint in combination with All and NotNull:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$builder = $this->createFormBuilder(); $form = $builder ->add('documents', 'file', array( 'required' => false, 'multiple' => true, 'constraints' => array( new Count(array('max'=>3), new All(array( 'constraints' => array( new NotNull() ) )) ) )) ->add('submit', 'submit') ->getForm() ; |
This works around a bug where 'min'=>1 is ignored.
If you’re using validation groups, you may notice that the All constraint is not being applied. Here’s how to fix it:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$builder = $this->createFormBuilder(null, array( 'validation_groups' => 'Test' )); $form = $builder ->add('documents', 'file', array( 'required' => false, 'multiple' => true, 'constraints' => array( new Count(array('min'=>1, 'groups'=>'Test')), new All(array( 'groups' => 'Test', 'constraints' => array( new NotNull(array('groups'=>'Test')) ) )) ) )) ->add('submit', 'submit') ->getForm() ; |
Note line 11: 'groups' => 'Test',
Technically we shouldn’t have to specify validation groups for the All constraint; in fact there seems to be no way to do this in YAML. Hacking it in as an option to All on the PHP side however seems to be working for me. YMMV. And as far as I can tell this last one is fixed in 2.6.
Some internal rumination that I thought would make a nice blog post. Stuff we’ve learned after a dozen years of dealing with startup software documentation.
Because most software is a moving target, the vast majority of end user documentation is out-of-date soon after it is created. Out-of-date documentation is worse than no documentation because it adds to, rather than detracts from, confusion. This problem becomes exponentially worse when maintaining documentation across multiple languages. It can become a nightmare when resources are limited.
To help prevent the documentation from turning into a problem, consider the following heuristics:
And of course:
If you’re working on documentation and have come across this post, I feel for ya.. Keeping the scope as small as possible will bear you in good stead.
Here’s an interesting feature of Google Apps that got me into trouble recently:
https://support.google.com/a/answer/33389
The “abuse” and “postmaster” accounts are monitored by Google and always active. Even if explicitly configured in your Google Apps interface, emails to these accounts will be accepted into a Google black hole rather than bounce.
To make sure you get copies of emails going to these, be sure to create “abuse” and “postmaster” groups, otherwise you *will* miss an important email or two. Note that these need to be created as actual group addresses.. the abuse and postmaster accounts cannot be added to other addresses as an alias.
One of the final credits from the 2011 movie Contagion:
Great. Plus a shout-out to the DoD no less.
By the way here’s Major Garett hot mic’ed on October 3rd, commenting on the possible Ebola case in D.C.:
Yet more git syntax I keep forgetting. To branch and create a new line of development from a specific commit, do the following:
git branch newbranchname a9c146a09505837ec03b
Add the -b switch to immediately checkout after branching.
Since the commit will likley be behind, use --force when pushing to tell git to ignore future commits from the original branch and start a new fork.
Web development frameworks such as Symfony these days bake-in a number of security features, CSRF protection being a fairly common one. I recently made the mistake of not scrutinizing Symfony’s CSRF protection defaults, which led to occasional confusing CSRF errors after a web app had been deployed.
CSRF protection embeds a code into both the generated form and some client-side storage mechanism (cookies, though I suppose this could work with an HTML5 client-side database or whatnot). On submit, if the value embedded into the form and the cookie value match, then we know the form is submitted by the user who originally requested it.
In Symfony, the CSRF cookie lifetime can be configured, defaulting to null, which falls back to session.cookie_lifetime value from php.ini. I had originally set this to be one hour, probably based on configuration examples from a year or so back..
Anyway, app users lately have been leaving forms open for more than an hour. This is a good thing: It means they are treating our web app more like a client side app, which indeed it is meant to replace. Took some sleuthing, however, to figure out why I was seeing the occasional CSRF error when everything else seemed hunky dory. I’ve now set this to
|
1 2 3 |
framework: session: cookie_lifetime: 0 |
which will retain the cookie for the length of the browser session.
Lesson learned. Know your timeouts. And for that matter, plan some time to review old assumptions.