PHPStorm's File template settings are very versatile. They allow you to not only make a file template, but also allow you to parse out redundant elements (such as licensing) in the template by allowing an includes section. In your File Template, any undefined variable automatically elicits a prompt from PHPStorm.

PHPStorm allows you access to the includes section via the #parse directive. If you're want To have Custom variables to be filled in correctly via prompt, you will need to have the variable declared in the template.

Example

"chance license.php"

/**
* @package ${Package}
* @author Chance Garcia
* @copyright (C)Copyright ${YEAR} chancegarcia.com
*/

In the above includes example, I'm wanting to have a custom variable named Package. I can only cause PHPStorm to prompt for this value if I include the variable in my template. If I'm already using the variable in the template, then it will fill in when the includes file is parsed.

Example:

<?php
#parse("chance license.php")
 
class ${Package}_#if(${ExtraClassInfo} != "")${ExtraClassInfo}_#end${NAME}
{
 
}

In the above template, the ${Package} variable will be given a prompt since it is used in the template and an unknown variable and the parsed "chance license.php" include will be able to use that prompt value.

I am also using another variable to Prompt for extra class name information. Since PHPStorm uses Velocity Template Language (VTL), I am able to use the VTL conditional syntax to insert that information if it is entered and ignore it if it is not. This technique is useful in a situation where you want your include file to have a custom variable value but do not need to display this value in your template.

Example:

<?xml version="1.0"?>
<!--
#if(${Package})#end
#parse("chance license.php")
-->

In the above example, we make PHPStorm prompt for the custom value needed for out parsed include file. This gives us our expected include file without printing our custom variable anywhere else in our template.

Over the last few days I’ve finally fixed a data enumeration bug that was haunting a new feature in Shazzer. Originally Shazzer just mutated one character at a time to discover characters which influenced the fuzz vectors in interesting ways. I decided to expand that to include data. I called the feature “datasets” because you could assign a placeholder to a set of data. Using this placeholder it then becomes easy for you to generate a vector that checks each value in the dataset and not only that but how that data relates to another dataset.

So what does that actually mean when it comes to vector creation? Here is an example enumeration vector:

<*datahtmlelements* *datahtmlattributes*="javascript:parent.customLog('*datahtmlelements* *datahtmlattributes*')"></*datahtmlelements*>


*datahtmlelements* refers to a dataset and in this instance we are talking about html elements, so the placeholder will be replaced by “br”, “b”, “html” and so on, the same this will happen to *datahtmlattributes* but this time using each attribute. Shazzer checks your vector for how many instances of placeholders you have and then automatically creates a loop within all the data so it enumerates each dataset within a nested loop of up to 5 separate datasets. The amount of data is split between a maximum of 10,000 iterations so your data will all be enumerated no matter how big the total iterations are it will just take a long time for a lot of nested datasets

You can see in the vector that the placeholders are used more than once this enables you to log any interesting results, so here we use the customLog function in Shazzer to send the html element and attribute that executes. Other logging functions are available and are listed in the preparation code when you create a vector.

Steps to create an enumeration vector

1. Check datasets for which data you would like to enumerate. You can create your own dataset if the one you require doesn’t exist.
2. Click create and select “Data enumeration” from the vector type drop down.
3. Give it a nice descriptive name and some keywords to find the vector.
4. You don’t actually need to modify the preparation code unless you need to log something that doesn’t execute like CSS values for instance.
5. Construct your vector by clicking and data placeholders at the bottom and craft you code as if you’re in a loop of all the data structures you use.
6. Once your vector is complete you can now fuzz the vector by choosing it from the “Fuzz vectors” list. Once you’ve found your vector you can select a doctype then click “Fuzz all” to begin fuzzing.

In future you will be able to share these enumeration vectors between your twitter followers in order to distribute the workload between friends to help scan large datasets. Happy fuzzing!

One of my goals this year is to acquire new skills, so I've decided to start by learning JavaScript. As was the case when I learned HTML and CSS, it's a tricky endeavor, because I'm not exactly a beginner, and most stuff is geared toward beginners, which can make learning so inefficient that I lose my motivation.

I've decided to treat this effort just like I treat exercise, which is to focus on rhythm and consistency above all else. Don't break the chain. My days are packed, but I'm setting aside at least half an hour each day to do something related to learning JavaScript. As long as I hold myself to that and continue making progress, I'll be happy.

Why am I telling you this? One reason is to put myself on the hook, and another reason is so that I can share what I'm doing to learn JavaScript, in case you want to join me. (This also means those of you who have already been down this path can offer your sage advice.)

Since I've just started, I'm currently only using two sources:

Eloquent JavaScript

This not only seems like a good introduction, but it also offers interactive exercises, which I think is going to make a big difference.

Codecademy

As you can see, I've already gone through some of the courses on Codecademy. The quality seems to be hit or miss, but I like the concept and the platform, and it allows me to dedicate very little time and still feel like I've made some progress.

I also have a copy of JavaScript: The Good Parts that O'Reilly sent me back when they wanted Sean and I to write a similar book for PHP. I'm not sure if it's best used as a guide or a reference, though.

If you're a developer and don't already consider yourself a JavaScript expert, won't you join me?

My previous post, The MicroPHP Manifesto, resulted in much excitement. In between fits of rage and crying, I found some time to answer folks questions, and also discuss the topic on the /dev/hell podcast with my cohost Chris Hartjes. To summarize and address some of the common questions, I felt I should write a small FAQ.

Got a question? Ask me. I’ll add additional entries here as things come up.

So you think full-stack frameworks suck?

No. I think sometimes they’re very appropriate. It depends on your needs: will the pros you get with library/component/framework X outweigh the negatives? If so, it’s probably a good choice. If not, it’s probably not.

You need a large framework to enforce best practices!

Sometimes you do. My experience at FictiveKin has been that our small team is able to work faster, smarter, and more efficiently by minimizing the size of our PHP codebase and removing all unnecessary layers of abstraction. In some cases that meant not doing certain tasks in PHP anymore (almost all HTML generation was moved to the browser). In others, it meant ripping out a bunch of code and replacing it with a simpler solution that required far less boilerplate and replication. We still kept some code that had more dependencies than we’d like because the wins we get with it outweigh the downsides.

I’ve certainly seen situations where choosing a popular full-stack framework is a better idea. As teams get larger, enforcement of coding standards and not doing Dumb Shit becomes harder. Hiring and training engineers is usually easier with popular, full-stack frameworks. On the other hand, we’ve found that devs coming from non-PHP backgrounds liked how quickly they can be productive with simpler libraries and frameworks. Your mileage may vary.

So you’re saying we should write our own framework/libraries/components?

Good God no. There is lots of very good, well-written code out there that’s already solved the problem you’re facing. Most of the time I don’t want to try to solve an issue like oAuth request signing, because it makes my brain hurt and I’d rather focus on building stuff. So, I’ll look for an existing solution that fits my needs first. I sometimes choose to write something from scratch because the existing solutions (that I can find – discovery is a whole other issue) don’t fit well with my existing application structure, or I feel it will introduce more maintenance issues than I’m comfortable with.

You should check out my microframework!

Sure. Generally I think people should work on writing libraries/components, personally. We have plenty of framework choices. But this is PHP, so you have to write your own framework sometime.

Is “X” a microframework?

Long answer: I tend to believe that the reference implementation of “microframework” is Sinatra. Routing, request/response objects, sessions, maybe some hooks for template rendering. Generally I think the inclusion of an ORM is a clear sign of non-micro-ness.

Short answer: I don’t care, really – and you shouldn’t either. If it works for you, awesome.

How do you choose what gets listed in the MicroPHP code collection?

Generally I think about these things:

1. Does it try to solve one task, or a small set of closely related tasks?
2. Would it be easy to use with almost any existing code base?
3. Is the code as short as it can be, while still being clear and easy to follow?

None of these are hard and fast rules, though. I encourage people to share things with me they think others would find useful.

Why do you hate Rush?

I don’t. I like some of their songs, but don’t own any of their work. I also think they’re incredibly smart, talented musicians. My point was to suggest there are other valid approaches, not to reject complexity outright.

A quick update about CSP. Browsers are well on their way to all adopt the specification.

An early draft was already adopted by Firefox 4, and I just found out that it's also working in Chrome, Safari and IE 10.

IE10 and FF are using the following header:

While Safari and Chrome use:

When the specification is finalized, the X- will be dropped, and it will simply be 'Content-Security-Policy'.

A call for support

Hi Developers! Start implementing this feature! It's important for the future and security of the web. The web's biggest vulnerability, from what I understand, is still XSS, but if people start to properly implement CSP, XSS can effectively be a thing from the past.

So even if you don't want to risk using CSP on a production environment, at least consider adding the headers in your development environment. It will force you to write better code, by not embedding javascript directly into the HTML source. By considering this right now, you will also make it much easier if you do decide to adopt CSP at some point in the future.

I'm implementing CSP full-on in a new project, and one of the things I've noticed already is that some of the javascript we embed from 3rd parties use eval() and inline html events (onclick & friends). For the sake of security we will most likely decide to only use 3rd party code if they are indeed CSP-compatible.

A quick update about CSP. Browsers are well on their way to all adopt the specification.

An early draft was already adopted by Firefox 4, and I just found out that it's also working in Chrome, Safari and IE 10.

IE10 and FF are using the following header:

While Safari and Chrome use:

When the specification is finalized, the X- will be dropped, and it will simply be 'Content-Security-Policy'.

A call for support

Hi Developers! Start implementing this feature! It's important for the future and security of the web. The web's biggest vulnerability, from what I understand, is still XSS, but if people start to properly implement CSP, XSS can effectively be a thing from the past.

So even if you don't want to risk using CSP on a production environment, at least consider adding the headers in your development environment. It will force you to write better code, by not embedding javascript directly into the HTML source. By considering this right now, you will also make it much easier if you do decide to adopt CSP at some point in the future.

I'm implementing CSP full-on in a new project, and one of the things I've noticed already is that some of the javascript we embed from 3rd parties use eval() and inline html events (onclick & friends). For the sake of security we will most likely decide to only use 3rd party code if they are indeed CSP-compatible.

It used to be that once a year I would take a good, hard look at the tools I used and endeavor to learn something new or change my workflow with those tools. However, I’ve been living the #startuplife for the past two years, so it’s been about three years since I last addressed my development toolchain. I decided to come up for air and take some time this weekend to rectify that by addressing five main areas: my terminal emulator, my shell, my terminal multiplexer, my IRC client, and my color scheme—yes, even my color scheme! In addition, I decided to push out my updated Octopress-powered blog, even though things are still a little rough around the edges.

Switching to iTerm2

I’ve been a long-time user of Terminal.app, but I had been hearing good things about iTerm2. I actually used iTerm (version 1) years ago, but I switched back to Terminal.app for reasons I cannot recall. Nevertheless, iTerm2 has come a long way, and I wanted to take advantage of some of its functionality like split panes, better full-screen support, etc. So, that was the first major change I made to my tools.

Ditching bash for zsh

Bash has been my favored shell since I began using Linux about fourteen years ago. I’d never given much thought to using a different shell, and to be honest, switching shells always seemed a daunting task. I thought I’d have to relearn my way around the shell, and everything I took for granted with Bash would be non-existent in a different shell. Fortunately, this is not true. As it turns out, zsh “can be thought of as an extended Bourne shell with a large number of improvements, including some features of bash, ksh, and tcsh” (Wikipedia).

I was able to switch to zsh without ditching my knowledge of bash. As a result, I’ve gained all the advantages of zsh, which include advanced customization and scripting capabilities, while continuing to provide most (if not all) the same functionality and commands I’m used to in bash. I have much more to learn, though, so if you have tips and tricks, please share.

If you’re interested in switching to zsh, I recommend checking out oh-my-zsh. It’s a framework for managing your zsh configuration, and it contains lots of goodies. In addition, there are great posts by Mark Nichols and Jon Kinney that will get you quickly up-to-speed with oh-my-zsh. The latter post has the awesome title “It’s not enough to bash in heads, you’ve got to bash in minds…with ZSH”.

Using tmux instead of screen

Generally, I’ve really only used screen when I started noticing that my connection to a remote development machine was getting sluggish or I wanted to keep a constant connection to IRC, but tmux has opened my eyes to so many more possibilities that a multiplexer can offer. I’ve just only started using it, so I can’t say much about it, but I encourage you to read Hawk Host’s two-part post on tmux.

Moving back to irssi

I used irssi in a screen session for years. Then, I decided I needed Growl notifications from my IRC client. I quit using irssi in favor of Linkinus. I’ve used Linkinus for about two years—together with the IRC bouncer znc for some of that time—but I’ve continued to miss the flexibility and functionality of irssi. On a whim, I decided to switch back to irssi, but it wasn’t without so

Truncated by Planet PHP, read more at the original (another 3132 bytes)