General Archives - Page 18 of 25 - {5} Setfive

A couple of days ago, a friend of mine looking to engage in the community asked me which experienced PHP developers he should follow on Twitter. An interesting question, and as I started looking through the @setfive follower list I realized we really don’t follow very many. Anyway, not wanting to leave him hanging, I put together a list of 5 developers that I thought were a good start.

This is obviously just a start, but I’d love everyone’s help to build out a list of solid PHP developers to follower on Twitter. If you leave them in the comments, we’ll pull together a single list and update this post once we have it!

Fabien Potencier

Co-founder and CEO for @SensioLabs, founder and project lead for @Symfony.
Tweeting from @fabpot and on the web at http://fabien.potencier.org

Jonathan Wage

Husband to @meganswage and director of technology @OpenSky. @ServerGrove @Symfony @DoctrineORM
Tweeting from @jwage and on the web at http://jwage.com/

Kris Wallsmith

Lead architect & symfony guru at @opensky. lead dev on assetic, buzz, spork. father of 3, widower of 1.
Tweeting from @kriswallsmith and on the web at http://kriswallsmith.net/

Chris Corbyn

Nerd, englishman, chatterbox, cake-a-holic, celery hater, Italophile, nu-melbournite, SitePoint/Flippa code monkey. I’m also @cosadici.
Tweeting from @d11wtq and on the web at http://chriscorbyn.co.uk

Dustin Whittle

Technologist, Architect, Open Source Advocate
Tweeting from @dustinwhittle and on the web at http://dustinwhittle.com/

Dries Buytaert

Creator of Drupal, Drupal project lead, co-founder and CTO of Acquia, and Mollom spam fighter.
Tweeting from @Dries and on the web at http://buytaert.net/

Lukas Smith

My twitter alter-ego is all about PHP and databases. My coding addiction is financed by @liip.
Tweeting from @liip and on the web at http://www.liip.ch/en

Joseph Bielawski

Software Developer – #Symfony2 #PHP Polish Twitter Translator
Tweeting from @stloyd and on the web at https://github.com/stloyd

Robin Muilwijk

Board member, eZ Publish Community Project Board : Open Source Advocate : Community Management : Social Media : Civil Servant : Information / Data Engineer
Tweeting from @i_robin and on the web at http://www.linkedin.com/in/robinmuilwijk

Anthony Ferrara

Anything Regarding Software Security, Performance, Quality and Architecture…
Tweeting from @ircmaxell and on the web at http://blog.ircmaxell.com/

Nikita Popov

18 year old student enjoying programming :)
Tweeting from @nikita_ppv and on the web at http://nikic.github.io/

Igor Wiedler

Philosopher.
Tweeting from @igorwesome and on the web at https://igor.io/

Matthew Weier O’Phinney

PHP and ZF Developer; crazed father of two.
Tweeting from @mwop and on the web at http://www.mwop.net/

William Durand

Student by day, full stack developer by night. Open-Source evangelist all the time.
Tweeting from @couac and on the web at http://careers.stackoverflow.com/williamdurand

Jordi Boggiano

Passionate web developer, specialized in web performance and php, #Composer lead, #Symfony2 developer. Partner at @nelmio, information junkie and speaker.
Tweeting from @seldaek and on the web at http://seld.be/

Giorgio Sironi

Developer at @Onebip. I search for the harmony between form and context. Software, science, economics.
Tweeting from @giorgiosironi and on the web at http://www.giorgiosironi.com/

Last week, at Google I/O Google announced a set of sweeping changes to their Wallet product. CNet has a decent run down of what they announced but basically it boils down to the ability to “send money with GMail”, Wallet integration into Chrome to decrease payment friction, and “instant buy” with Google+. All in all, the announcements are interesting but I think what’s more exciting is the potential for Google to truly innovate in the payments space.

In the last few years, companies like Square, Dwolla, and Stripe have been innovating in the payments space but they’ve all been reliant on existing credit card infastructure. With the exception of using Dwolla as a replacement for a check, each of the companies still relies on charging a user’s credit card to complete the transaction. I think this infrastructure piece is the key pinchin for Google Wallet. If Google can sidestep the existing payments infrastructure for Wallet, like they did with the telcos for Fiber, they’ll end up redefining how digital payments work.

Ok, so they own the infrastructure now what can they do?

Better risk analysis, lower costs

As far as processing payments go, cost is ultimately one of the most important factors used in picking a processor. The pricing is so opaque that FeeFighters basically built and sold a business simply by explaining in straightforward terms which processor was the best for your business. If Google had the freedom of controlling the pipes, they’d be able to lower their pricing below everyone else by introducing better risk analysis tools into their payment solutions.

Looking at how the APIs from companies like Authorize.net work, they basically only accept the minimum information required to charge a credit card and nothing more. Google would be able to modernize this by incorporating additional “verifying details” about a user to reduce the risk on a transaction. For example, a charge originating from a 2-factor authenticated Google Wallet user that is at their “home” computer is obviously much less of a risk than an anonymous user using a credit card for the first time. By segmenting risk by user, device, as well as transaction type Google would be able to offer the best rates for “normal” transactions and also accept “high risk” transactions.

Give NFC payments some teeth

Google has tried to push out the NFC powered version of Google Wallet in 2011/12 but it was immediately blocked by major American carriers because it competed directly with their ISIS solution. It shouldn’t come as a surprise that the telcos didn’t want to get relegated to “dumb pipes” for payments as well but it’s also not like ISIS has garnered any real traction either.

If Google controlled the entire stack and could successfully convert Android users to Wallet users, they’d be able to essentially pay the carriers “blood money” to lift the Wallet ban to drive adoption and then hopefully reach a more permanent deal.

Ultimately, true mobile payments need to be freed from the existing credit card restrictions and Google could be poised to deliver just that.

Micropayments that work

People have been talking about “easy” micropayments on the Internet for several years but they haven’t really shaken out. Even today, charging someone $1 for something is a huge PITA and it really isn’t even practical. Between fees and long payment forms, the micropayments still aren’t economically feasible.

With Wallet integrated into Chrome and the infrastructure under their control, Google would be able to tackle this head on by reducing the friction to completing a payment and offering different pricing models for micropayments. Think 2 click checkouts for transactions under $5 and a monthly fee of $5 for merchant accounts in good standing instead of transaction fees.

Despite some reservations, I’m excited to see what Google ends up doing with Wallet and how it ultimately influence the payments space. Another big question is what’s Facebook going to do? Revamp Facebook Credits? Start offering co-branded Facebook credit cards?

Anyway, thoughts or comments welcome.

As some of you may know we right now are hiring a mid-level engineer for our team. We’ve noticed in the past few weeks quite the influx of recruiters calling us trying to fill the position. As a company we’ve never used a recruiter in the past, its not that we’ve been closed minded to it, it’s just that we never have had a good experience with one for multiple reasons. We’re paying the recruiter part a fee for finding us these great people, so they should be doing a little work on their end too.

With a recruiter we expect that the applicant has been pre-screened so that they match what we’re looking for roughly. Half the time we have anyone call us they don’t even know what type of company we are, come on at least visit our webpage. I don’t want to have to explain that we are a PHP shop with a heavy Symfony influence, you should already know that. Of course, once we mention PHP and that we’re looking for a mid level person, the recruiter always has someone that we need to talk to. This is the best fit for us.

This brings me to my second pet peeve, non-technical recruiters doing technical recruiting. Now the recruiter know’s we want PHP developers, so they filter their resumes by PHP. Often the next question is oh are you using Apache? Tomcat? IIS? Node? For the most part, what does this have to do with it, but no we aren’t primarily using java or a javascript web server. Often it is clear the recruiter who insists they’ve personally screened the person has no clue what they are talking about, they just are trying to match keywords to a resume.

Third, stop pushing to get me to come to your office to interview candidates I have no idea who they are. Often on these calls after they’ve learened who we are and what we want, they want me to jump on a call or come into their office to do interviews with their perfect match candidates. Everyone is busy, I want to see some resumes before going into these first round interviews, otherwise they could be a total waste of both our time.

Lastly, we’re a consulting firm, this means we have clients. I can’t tell you how many times a recruiter doesn’t look at our clients list and then proceeds to give us people who still work for our clients. A heads up, most of our contracts do not allow us to hire directly from a client while we are engaged with them (some even for a period there after). Nevertheless, if the client ever saw us and thought we’d were stealing or aggressively recruiting their employees we can kiss that relationship good bye.

What do I want from a recruiter? First, I want you to have some technical knowledge, at least know what groups of technologies go together and that LAMP is not a word but an acronym. Second, take 5-10 minutes, look at our website, projects, blog, and clients make sure whomever you are telling us is a great fit actually has a good chance of being a good fit. Third, send me a resume, remove all the contact information if you’re worried about us going direct to them, before trying to push me to either jump on a phone interview or come to your office.

Finally, if I’ve said no thank you we’re fine for now, do not continue to email and call me saying that you do have a better candidate.

This may come off as a bit of a rant, but really I hope some recruiters read this and understand that we would be happy to look at your candidates if you’ve put a little effort into making sure they are actually a good fit.

Over the weekend, Fred Wilson posted an awesome video of the unboxing and flight of a Parrot AR drone along with a note that he was planning to grab one and develop some custom node.js code for it. After seeing the video, and with spring finally here I started brainstorming about what gadgets I’d want to play with over the summer.

Parrot AR Drone

Shown in the video linked above, the Parrot AR Drone is a remote controlled 4 rotor helicopter that is controlled via an iOS or Android device. What sets the Parrot apart from other similar devices is that it there is an node.js library for simplifying development of custom functionality on the Parrot platform.

Not exactly sure what we’d be looking to build with an AR drone but the Red Bull Air Race comes to mind.

Sphero Robotic Ball

Built by Boulder, CO based Orbotix the Sphero robotic ball is a gyroscopically stabilized ball that can be controlled using an iOS or Android device. The Sphero has a software development SDK and there’s also an active app store to download pre-built apps that work with your Sphereo.

Just brainstorming, but something awesome to build with a Sphero would be an app to draw out large drawings using the Sphero to actually draw the lines. Imagine drawing a 50’x50′ line art graphic by uploading some art and then letting the Sphero roll around the canvas.

Pebble watch

Born on Kickstarter, the Pebble watch is an indie entrant into the “smartwatch” space. Sporting iOS and Android integration via Bluetooth along with a scriptable watch face, the Pebble is shaping up to be an interesting player in a developing market.

As far as development, writing custom faces to visualize information differently or pull data off a smartphone seems to be pretty exciting. It still seems a bit early to get a sense of how the Pebble will fare long term as a platform though.

Jawbone UP

Although primarily known for their speaker systems and Bluetooth headsets, the Jawbowne UP is a personal activity monitor that helps users track their physical activity, sleep cycles, and eating habits. The UP fits into the trending theme of the quantified self, where users track KPIs about their daily life in an effort to iterate and improve. Pulling data off the UP is relatively easy and it also plugins in to RunKeeper.

The “quantified self” concept sounds like it would be interesting to experiment with and using the UP to try it out seems like an obvious choice. Leveraging the UP would also make it easy to “compete” with anyone else looking to jump into activity tracking.

Raspberry Pi

Released last year after intense anticipation, the Raspberry Pi is basically a six square inch board with a fully featured computer including video output and USB ports. Coming in at $25 or $35, the Raspberry Pi is cheap enough to experiment with, hack it, and if it happens break it. With full Linux support, the Raspberry Pi is also robust enough to handle “serious business”.

Looking at the list of Rasberry Pi Hacks, theres definetely some awesome inspiration to build something cool. Using a Pi to power a TV screen with real time interactive content seems like it might be an early winner though – we’ll see where that goes.

Anyway, that’s my list, unfortunately I’m not sure what I’ll actually get around to hacking on this summer. Would love to hear about any other cool gadgets or hacks.

Last week, I was putting together a Google Chrome extension for one of our clients to help debug Javascript events on a page and I started wondering why don’t we have mobile browser extensions? Unfortunately, there isn’t a simple answer but I think looking towards the desktop can help draw analogies to where we are on mobile now.

So this desktop thing?

Looking back to the desktop, arguably one of the strongest drivers of Firefox’s growth was its rich extension ecosystem. Compared to Internet Explorer, Firefox extensions were easier to develop, leveraged web technologies (XUL, JS, CSS), and offered powerful abstractions out of the box. Because of this, developers began building powerful extensions for Firefox which drove “power user” adoption and ultimately helped spur mainstream adoption. Developers built extensions like Firebug, Greasemonkey, and companies like Rapportive inside the Firefox extension ecosystem. Following Firefox, when Google Chrome launched it debuted its own even simpler extension infrastructure and eventually the Chrome Webstore to help distribute and monetize extensions.

Although largely positive, the extensions developed for Firefox and Chrome weren’t always user friendly. Between redirecting search traffic and surreptitiously injecting ads, “greyhat” extensions negatively impacted user experience while generating revenue without generating value. These “greyhat” extensions fueled what’s colloquially known as Israel’s download valley and ultimately millions of dollars in revenue.

Right so what about mobile?

Compared to the desktop, the landscape on mobile is notably different because of an Apple and Google duopoly with Apple primarily monetizing hardware and Google monetizing search advertising. Additionally, compared to the desktop, Apple and Google have an unprecedented level of control over user devices, all but ensuring that devices will arrive with either Safari or Chrome installed.

I think because of this control, Apple and Google have little incentive to open up Mobile Safari or Mobile Chrome to 3rd party extension developers since doing so would compromise the browser user experience for little gain over the competition. But what about Firefox?

Although Mozilla has released a Firefox build for Android, I think they’ve recognized that trying to win market share away from Chrome on Android is a losing battle and they’re starting to seriously pursue FirefoxOS. Because of this, I don’t think Mozilla will invest in Firefox mobile extensions since it’s clear that there’s more opportunity in powering the OS layer of a user’s phone.

Category: General

PHP: Seven PHP developers you should be following on Twitter