If you’ve been following the development of PHP 5.5 you probably already know that the Zend Optimizer Plus has been released under the “The PHP License, version 3.01″ license, renamed to Zend Opcache, and merged into the PHP 5.5 code base. Last week PHP 5.5.0 beta-1 was released, which is the first version to include the Zend Opcache.

CK has built a simple Zend Opcache control panel, which you may find useful. The code is available at https://gist.github.com/ck-on/4959032/?ocp.php.

Have you ever wanted to give your model some month choices relating to integers 1-12. I would guess it’s pretty common – common enough to be included in django.contrib. Well, it is. Here is a quick tip on how to include it in a model:

Related posts:

1. Python, Django & the Google Adsense API I have been tasked with updating our real-time revenue stats...
2. Django Textile/Markdown Template Caching Speedup I’ve been putting some time into updating an old site...
3. Django Custom Upload Handler to Compress Image Files I got a somewhat unique request on a project the...

Related posts brought to you by Yet Another Related Posts Plugin.

Each Saturday evening I put gas in our cars, usually just the minivan since my car doesn’t given driven as much. For as long as I can remember gas prices have included a 9/10s of a penny in the price per gallon. This always stood out to me because you don’t normally see prices listed with fractions of a penny. It is so uncommon that I think most people completely ignore it.

The reason they do this is clear, they make more money. While I don’t think you can charge a credit card a fraction of a penny, most people don’t buy just one gallon of gas. To keep things simple lets say I bought 10 gallons of gas for the minivan last week. Without the fraction of a penny the price would just be $3.24 * 10 = $32.40. With the fraction of a penny it is $3.249 * 10 = $32.49. They made an extra $0.09 from my purchase. Go on to multiply that by the number of other people who made similar transactions at the same gas station that day.

I don’t think we are talking huge numbers here by themselves, but the cost to generate that additional revenue is super small. The computers in the pumps just need to be able to calculate the price correctly, which the have to do any way. Even if a gas station is only making an extra $500 per day by adding on an extra 9/10s of a penny, the cost for that extra $500 is nearly zero.

This type of pricing pattern really only does well for per unit pricing where people nearly always buy more than one unit at a time. If everyone only purchased one gallon of gas at a time then the fraction of a penny really wouldn’t make a difference.

The other place I’ve seen fraction of a penny pricing is Amazon Web Services. Here is the EC2 pricing for light utilization reserved instances:

The EC2 pricing differs from the gas pricing in a couple of ways. First, not all of the EC2 fractions of a penny are 9/10s. Second the per unit pricing (one hour) of EC2 is so small that the fractions of a penny make up a significan portion of the price. That probably also explains why they aren’t all 9/10s of a penny.

Amazon isn’t the only cloud service for which this applies. Look at the pricing of Google Compute Engine as another example.

Since these last two examples involve computers and fractions of a penny, I’ll let Richard Pryor take care of the rest:

What other products or services do you purchase that consistently set their prices at a fraction of a penny?

A lot of people will tell you you shouldn't put sourdough in metal. Some even go so far as to say you shouldn't use a metal spoon to stir it. That's all nonsense. It's not hydrochloric acid, it's food.

However, when you leave sourdough in a vessel for an extended period of time, and that vessel is not non-reactive, it will react. (The same as tomato sauce will.) It turns out, aluminized steel is one of those substances, and my precious Chicago Metallic pan is ruined from a few very long and sour proofs (10+ hours). Also a lot of scratches from metal knives trying to release stubborn loaves, have taken their toll. As it turns out aluminized steel is steel coated with an aluminum-silicone coating, so you should probably treat it as you would non-stick, even if it claims to be "uncoated" (meaning it doesn't have a non-stick coating). Use plastic utensils to wage war with your stubborn bread.

I'm not sure whether regular non-stick coatings are non-reactive or not, but I'm not a fan of tiptoeing around my cookware so I avoid non-stick.

So I'm buying a Stainless Steel Loaf Pan. I considered silicon too, but I hear horror stories of bad smells at high heat and not keeping their shape with a heavy loaf. And I'm not sure if they'll brown well (stainless is supposed to be less-good for browning that aluminum or aluminized steel, but oh well).

If you already have aluminized steel pans I'm sure you can bake sourdough in them, just watch out for long sour proofs, and use plastic.

North-bound travelers on I-15 through Lindon, Utah will find a recruiting billboard from local tech startup Domo that many will find either shocking, offensive, oddly funny or just downright lame.

Odd billboards from Domo’s chief, Josh James aren’t a new thing. It’s kindof his schtick, hailing from days back at Omniture (now Adobe) and even using secretive billboards to attract people to his newest, then-stealthy gig, which turned out to be Domo.*

Designed to read like a classified ad (in the personals section), the ad reads:

Sexy young startup seeks hot engineers
4 a good time, go 2 www.domo.com/jobs

Initially, this ad is clearly trying to play a joke on the idea that Domo is putting out ad after ad to hire engineers, something akin to putting a personal ad out or joining an online dating site (insert golf clap here). This is something that’s not lost on me or the recruiting industry in-general, but I have always felt this conversation that “recruiting is like dating” just lends itself to the wrong kinds of allusions.  The last thing we need in the world today are more hiring managers going about hiring staff like they would try to find a date for Friday night.

However, thinking just barely beyond the initial impression, it becomes clear that this billboard is, at a minimum fairly tasteless, but in the extreme, highly offensive to both women as well as any self-respecting professional looking for work.

• Are Domo engineers hotter than other engineers? I mean, if this is what’s being recruited for, they should have an unusually attractive workforce…
• Are candidates measured by hotness? Is there a technical term for that? What programming language(s) do hot people write in?
• If your hotness quotient should diminish over time, are you passed up for promotions or does your percentage in the bonus pool shrink? As an analytics/dashboard company, are these rankings published (with photos, of course) on the internal intranet?
• I’m not sure – Is this an ad for a long-term relationship or more of a one-night-stand type thing?  Would you want to work for a company that just wants to NCMO?
• How would you feel after being hired to find out that the next engineer hired is actually getting all the attention? Would you be jealous? Is this a precursor to an episode of Sister Wives?

All jokes aside, while the billboard isn’t technically sexist (It doesn’t specify that the sexy startup is masculine or feminine or that said sexy startup is seeking a preference of males or females), it does lend itself to a pretty cheap kind of relationship between the employer and the employee.  If being hired is like being selected for a date, what kind of experience should a candidate–or employee–expect to have in that environment? I’m not going to lie, I am pretty shocked that Human Resources didn’t step in and squash this billboard pretty fast.

Look, if an employee in a company I worked with put up a sign outside their office saying exactly this when they began hiring for a specific job to fill, it would be taken down pretty fast by either request or by force. Even if there’s, perhaps, nothing immediately harassing about what this sign says, it sure smacks of it and that’s pretty plain to see. I wouldn’t recruit on a job being advertised this way.  If the company is just looking “4 a good time”, then what does that make the recruiter??

* Disclosure: I used to work for JJ at OMTR. Have no idea if this matters, but since there’s a connection here that might not be readily apparent, I figured I should say something.
Related Posts:

• LinkedIn: Indicator of Internal Company Mood #recruitertips
• Using Google Forms to Aid Campus Recruiting
• Hiring Good Programmers?
• 72% of Orgs Do Not Recruit With Social Media
• Layoffs and Restructure at Google

As we enter 2013, I’m thinking of additional ways to improve the Utah Tech Jobs website. I’m thinking it would be great to add list of resources that would be valuable for people who are seeking new or different employment.

• Use Your LinkedIn Profile as a Resume
• Companies Asking for SocialNetworking Passwords Should be Outed Online
• Still Sending Out Resumes? You’re Doing it Wrong
• Making a First Unimpression
• Twitter Datacenter Opens in Utah

Warning: This article is long and thorough. If you’re in a hurry, you can skip straight to the final product here:

http://plnkr.co/edit/6KxHY8ZpE83Z2PeNWlYi?p=preview

Before reading this, get to know these AngularJS terms. You don’t need too much depth, but you need to know what they are:

• Directive
• Scope
• Controller
• Injecting services into controllers
• ng-show and ng-hide
• ng-click
• ng-model
• ng-repeat

You should also peruse the Angular Developer Guide, but don’t feel bad if a lot of the jargon does not make much sense at first.

We’re going to create two custom directives that communicate with each other. We’ll really dig deep into the first directive, explaining every line of code as we go.

Then we’ll glue the directive to a controller via a scope object.

Lastly, we’ll create a second directive and glue it all together.

For this example, we’ll create a custom search box that can be placed in our app with a custom <my-search-box> element. This directive causes Angular to convert <my-search-box> in your HTML into <span>My Custom Search Box</span>. This is not useful yet, but it will become immensely useful as we grow this concept in a few paragraphs.

We’ll create a file called “app.js” with this content:

Let’s walk through each line of that directive:

This line declares a new module called “MyApp”. The empty array to the right can contain the names of other modules on which this module depends (this is where you would put AngularUI modules for example if you want to use AngularUI). In this case, this module happens to be our “main” application module, but Angular really doesn’t know that from this line of code. That happens in the HTML with <html ng-app="MyApp">. Also, you only declare your main application module once, even if you have many directives. There are ways to look up your module if your code spans multiple files, or you can just create a global variable to reference your module and use that when building your directive.

Here we are declaring a new directive. Notice that we camel case the directive name. When Angular encounters <my-search-box> in the HTML, it will normalize that into “mySearchBox” to look up the directive. Thus, “mySearchBox” is called the “normalized” name.

Angular expects the directive function to return an object with properties that describe the directive.

This tells Angular that “my-search-box” must be an element. Angular directives can also exist as HTML attributes, HTML class names, and even HTML comments (!). It’s okay if this doesn’t make sense yet.

This tells Angular to fully replace <my-search-box> with the directive’s template HTML. Alternatively, Angular can add the directive’s template HTML to the <my-search-box> element as a child element. For our example, we want Angular to fully replace <my-search-box> because <my-search-box> is not a valid HTML element name. You can imagine wanting Angular to simply augment an element with child elements in some scenarios, but not this example. We’re effectively creating a “widget” that can be instantiated and reused in our HTML.

This is the directive’s HTML template that will be rendered by the browser. I don’t recommend using hard-coded template strings in your directives like I’ve done here. I do it this way to make the example clear. Normally, I use the templateUrl property and serve the HTML as a “partial” from my web server. Angular caches these partials, and you can even pre-load them when your app loads. This way, I can use server-side template technologies for things like localization. Although, for the best performance, I recommend that you serve these partials statically from a CDN or other fast caching service.

Now we can use this directive in our HTML like this:

When you visit that page in your browser, you’ll see “My Custom Search Box” if all went well above.

So far this is a pretty useless directive, but we’are about to take it to the next level.

Each instance of a directive has its own scope. And of course, the scope is a child of the enclosing scope where you instantiated the directive in the HTML. For example, if your directive exists inside a <div ng-controller="MyController">, then your directive’s scope will be a child of MyController‘s $scope.

For example, the following HTML uses two <my-search-box> elements. Angular gives each <my-search-box> its own independent scope:

Let’s define our directive’s interface to the outside world using the scope property. Our interface will have two values: searchText and isSearching. We will use searchText to store the user’s search text that they enter into an <input> box, and we’ll use isSearching to tell the directive when a search is in progress.

Did you see the scope = {...} property above? That defines the public elements of this directive’s scope. Notice how we used '='? That tells Angular that we want a scope variable to have two way binding to the outside world. This is part of the directive’s HTML interface. This allows callers to use our directive like this:

In other words, the directive allows outside callers to bind their own scope variables to this directive’s searchText and isSearching variables. This is how you communicate with the directive from the outside world.

The variables someScopeVariable and someOtherScopeVariable come from the enclosing scope, which usually is managed by a controller outside the directive. If, for example, we had <div ng-controller="MyController"> enclosing <my-search-box>, then someScopeVariable and someOtherScopeVariable would be managed by MyController.

In the code above, the search-text gets normalized into searchText in the directive’s scope. Likewise, is-searching becomes isSearching.

When we assign search-text="someScopeVariable", we are telling Angular to bind this directive’s searchText scope variable to a scope variable from the enclosing scope called someScopeVariable. Any time the enclosing scope’s someScopeVariable changes, the directive’s scope variable searchText will also change. And it works in the other direction too. Any time the directive changes its searchText variable, Angular will automatically change the enclosing scope’s someScopeVariable to match.

These scope variables are useless unless we also make them visible somehow, so let’s modify our template HTML to use them. While we’re at it, let’s make this actually look like a search box instead of a simple piece of text:

Remember, I suggest you use templateUrl instead of template when your HTML starts to grow like this.

Now we have a search box form that lets the user enter some search terms, which we store in the directive’s scope as localSearchText. Notice that we didn’t put localSearchText in the scope: {…} definition, because it needs no external binding. In other words, this is a “private” scope variable that the directive uses to store the human text input until we are ready to actually do the search. This is because we don’t want every single keystroke to initiate a search. Only when the user clicks the “Search” button.

Notice also that we added a controller with controller: function($scope) {...}. This code defines a typical controller so our directive can take action in response to user input, like button clicks with ng-click.

This HTML also provides a “Clear” button to zero out the search box and a spinner to show when the search is in progress. The directive relies on outside callers to tell it when a search is in progress by setting the isSearching variable to a “truthy” value.

After making these changes to app.js, our page should look like this:

Now that directive is finished. Notice it doesn’t do much. It requires an outsider to stimulate it into action.

Let’s create a controller that communicates with the directive we wrote. This isn’t strictly required to allow two directives to communicate, but in most cases it will be necessary because someone has to glue them together with the business logic specific to your application. This is a job well suited to an Angular controller.

Let’s make a simulated city search that allows the user to search for cities. Because it’s an example, the search will always return the same results.

And the accompanying controller, which I placed in app.js:

This controller’s $scope.citySearchText and $scope.isSearchingForCities variables are bound to the directive’s scope variables searchText and isSearching because of the HTML attributes that we specified on <my-search-box>.

This controller is pretty basic, so I won’t describe every line of code. All it does is $watch() for changes to citySearchText and get some fake search results with Angular’s $timeout service.

Because of Angular’s excellent isolation-centric design, this controller would be very easy to write unit tests for, but that’s another article.

When you visit the page, you should now see a search box. If you enter some text into the input box and click “Search”, you’ll see a spinner for 1 second, which then disappears:

Now we’re ready to add another directive. For this example, we’ll create a search results directive. This directive has almost the same public interface (i.e., scope) as the <my-search-box> directive, with one extra variable: the actual search results that caller wants to display.

It looks like this:

Everything should look familiar from your study of the first directive. There are no new concepts here. Let’s use our directive in our HTML:

Now your page should show some search results after clicking the “Search” button and waiting for 1 second:

Just to prove that there is indeed zero coupling between the two directives and the controller, I added a second controller and a second instance of each directive to search for fruits, which you can see in the plunk below.

Here it is: http://plnkr.co/edit/6KxHY8ZpE83Z2PeNWlYi?p=preview

From the sheer length of this article, you may think that this is complicated, but the reality is that it only took me about 30 minutes to whip together the working example in the plunk.

Main points I hope you took from this article:

• Directives are easy to create.
• Directives have their own scope
• Directives can communicate with the outside world via HTML attributes
• Directives encourage loose coupling
• Directives encourage reuse and UI consistency
• Directives are easy to test (well, this is a future article)
• Controllers can use directives with zero coupling
• The Prime Directive has nothing to do with AngularJS (bummer)

Sallie Krawcheck poses an interesting question on workplace flexibility in LinkedIn’s 50 Big Ideas for 2013:

The US economic recovery is tepid at best, with growth in short supply. At the same time, progress on gender diversity has stalled, with the number of women in senior roles plateauing.

Solving the second challenge can help the first. Fully engaging women in the economy can increase GDP by as much as 9% … but it will take some very different thinking.

What do you think? Read more and comment, below?
Related Posts:

• Why Do You Work Where You Work?
• New Office Policy
• Telecommuters Gain 2.5 Days Productivity Over Office Workers
• Breaking News: Employees Want Respect
• What Are The Best Companies to Work For in America?

For years, web application developers have used DOM manipulation tools like jQuery to control their user interface. Astute developers have taken it to the next level with client-side templating tools like Mustache and Handlebars.js to build sophisticated user interfaces on the client side.

And then AngularJS came along.

And we all realized we’ve been doing it wrong.

Way wrong.

Remember before you discovered AngularJS? Back when your code was organized like this:

1. HTML that defines your page
2. JavaScript that downloads AJAX data
3. HTML that defines a client side template
   (yeah, this: <script type="text/html">...</script>)
4. JavaScript that renders the client-side template
5. JavaScript that injects the rendered template HTML into the DOM

You thought that was pretty cool. “Hey look,” you said, “I’ve off-loaded template rendering to the browser!”. Yeah, you were pretty cool.

But then AngularJS showed you how you were wrong. You could accomplish the same client-side magic with a lot less code.

Under AngularJS, your code can be organized like this:

1. HTML that defines your page and client-side templates inline
2. JavaScript that downloads AJAX data

How does that even work? I mean, you’ve got like less than half of the bullet points now.

The answer: Data Binding.

Data Binding is the secret sauce of AngularJS (along with a couple dozen other delicious spices and condiments). Oh, and it’s not a secret at all. The code is actually pretty easy to read, despite being pure magic awesomeness on environmentally-friendly steroids.

This should be very familiar. You’ve got an HTML page, and you want to add some dynamic content with a client-side template:

Here’s the page HTML:

Let’s use Handlebars for the client-side template:

And you need some JavaScript to download the AJAX data, render the client side template, and inject it into the DOM:

Put all that together somehow, and wow, that’s a lot of code to do something that should be very simple.

That covers all 5 bullet points above. You’re still cool, right?

Remember how there are only two bullet points. Well, here they are:

First, your page HTML:

Did you see that? There’s no <script> hack. The template is right inside the page! Right there. In-line. Right where you wanted it all along, but never had the guts to ask. But I digress.

Second, the JavaScript:

And that’s it. It really is glorious. The AngularJS team really distilled the client-side template problem to its essence and produced an elegant solution. But don’t take my word for it. Check out the win list below.

Look at all the prizes you won by using AngularJS:

1. CSS classes are just for CSS now.
   You used to abuse the HTML class attribute so you could find elements in the DOM with jQuery. Now, your class attributes are only for CSS. You don’t have to wonder anymore whether a particular class is used by JavaScript or CSS. The answer is always CSS: The way nature intended
2. No <script> hacks.
   You don’t have to trick the browser into ignoring your client-side templates anymore. Don’t you feel cleaner?
3. Client side templates are cohesive with your page
   You used to have a pile of client-side template files scattered throughout your project, or all crammed into your HTML <head>. Now they are right in the page, exactly where you wanted to read them in the first place.
4. You don’t have to name every template
   You used to name each <script> element with an “id” attribute to make it findable by jQuery. You can nuke those strings in your JavaScript and HTML, and not worry about them getting out-of-sync.
5. You have control over the scope of your JavaScript
   Previously you had to worry about your jQuery selectors casting too wide a net and selecting elements beyond what you intended. For example, suppose there happened to be an element in the page somewhere with class “animal”, and you didn’t know about it. Then you wrote a jQuery selector like $(“.animal”). Boom, you just mofidied an element you didn’t intend to. With AngularJS, your JavaScript cannot reach outside the ng-controller demarkation.
6. You don’t have to remember to clean up HTML on refresh
   Let’s say I want to refresh the animal list in this example. Under jQuery, I have to remember to do this: $("#my-list-of-animals").html("") before I start .append()ing new animals. In AngularJS, I just replace $scope.animals with the newly downloaded list, and it automatically clears out the old HTML.
7. Your JavaScript is cleaner
   Your JavaScript has no CSS selectors anymore. It used to be littered with strings to locate elemenents in the DOM. Now it’s just got business logic. Pure, sweet business logic.
8. You can unit test your JavaScript without a DOM
   I should have mentioned this first. Notice how my JavaScript has no knowledge of a DOM? It doesn’t even know there’s HTML involved at all. This makes it much easier to unit test, because you don’t need to load a big chunk of fixture HTML to test your JavaScript. AngularJS provides some great docs on testing too.

I started reading about AngularJS and re-working parts of my projects to use it in earnest only a few weeks ago. A day into the effort, the light bulb went on for me:

I’ve been doing this all wrong

At that point, I started to wonder why the AngularJS team didn’t write article after article with the same title: “You’re Doing It Wrong”. And that’s what inspired me to write this.

So there you have it. An opinionated blog post about an opinionated framework.

The Harold B. Lee Library at Brigham Young University in Provo, Utah is immediately seeking a full-time Software Developer with interests in big data and archival/library technologies to assist us with our new digital preservation project.

Responsibilities:

• Design, develop and support systems which benefit library patrons or extend purchased library systems
• Communicate with all stakeholders regarding commitments and requirements of all participants and users
• Hire, train and manage student employees to assist in development projects
• Keep up with new developments and technologies in digital preservation, library science, digital libraries, and integrated library systems
• Attend appropriate training or professional association conferences

Skills:

• In-depth familiarity with software development principles
• Java (prefered), C(C++), PHP or other mature programming language
• MySQL or Oracle database development
• XSLT(highly desirable)
• HTML, CSS, JavaScript
• Experience developing using Linux or a similar operating system
• Experience with Ex Libris products (highly desirable)
• Excellent communication skills including the ability to communicate technical issues clearly with non-technical employees
• Ability to manage projects which cross organizational lines and to direct team members who do not report to the incumbent

Requirements:

• Bachelor’s degree required, preferably in Computer Science or related field
• 3-5 years experience with Java, PHP or other mature programming language
• 1 year programming database applications.

BYU offers excellent benefits including group medical, dental, disability, life insurance and a selection of retirement programs. Other benefits include a tuition benefit, wellness program, and employee discount at the BYU bookstore and to athletic events. Employees also enjoy access to the Harold B. Lee Library and other BYU Facilities. For more information follow this link.

Preference given to members of the Church of Jesus Christ of Latter-day Saints.
To apply: http://yjobs.byu.edu/applicants/Central?quickFind=76275
Related Posts:

• Java Ninja
• PHP Engineer / Developer
• Senior Management Software Engineer
• Fusion-io: Senior Software Engineer: Scalability, Performance
• Director of Technology at Doba.com – Orem, Utah

This post was submitted by Curtis Thacker.

This is awesome! Thanks Joe!

Comments: 0

Comments: 0

I'm excited!

Comments: 0

Comments: 0

Comments: 0

Comments: 0

[url=http://www.buytoocheap.com]Cheap Burberry Shoes[/url]
[url=http://www.buytoocheap.com]cheap coogi clothing[/url]
[url=http://www.chinabeltsshop.com]cheap prada belts[/url] […]

Comments: 0

Comments: 0