That’s where social networks like MySpace, hi5, and orkut come into play. While Facebook might be the largest social network and the most used in North America, MySpace still retains a loyal set of users. Networks like hi5 and orkut maintain strong regional networks, with others like Vkontakte commanding small, but extremely engaged regional users.

Facebook is effectively a ‘me too’ developer arena, with an aggressive and unfriendly referee in Facebook Corporate. Most of the spamish tools used by Zynga and Playfish to grow their networks during the last redesign renaissance are gone now. Wall posts? Gone. Stream Posts with lots of images and spammy links? Gone. Notifications? On the way out baby. Facebook is attempting to detatch themselves from developers that helped increased the retention of their platforms by reducing branding and making it difficult for new developers to grow their audiences. With the introduction of Facebook payments, the writing is on the wall for companies like offerpal and trialpay as well.

So, what’s a developer to do? Social networks arn’t going away, and there’s still money to be made developing for other platforms that are looking to lure developers of A-list apps away from Facebook. MySpace is trying to do exactly that with a revamped API and a development contest aimed at giving developers something else to playwith on the platform. To be honest, there are some fairly interesting ideas in the streaming apis, borrowed from what Twitter is up to lately with its streaming API. It’s a huge waste of time and money, tho. The MySpace API’s are poorly documented and don’t really focus around what developers need to pull from the network on a regular basis (Friends, Userdata, Viral Channels). What’s worse, all of the MySpace API interactions are governed by what must be the worst authentication system ever imagined in Google’s OAuth for Opensocial.

Just look at the work flow for this beast of an authentication system. Wanna get some information from the user? You need ten steps to make that happen. Five full request / response cycles to make anything happen if the user isn’t authenticated. MySpace will let you skip one of those cycles if you’re making the request from an already authenticated user within one of their application pages, but you’re still going to walk through the overly complicated process of authentication to do almost anything. You could use the MySpace SDK for most platforms, and they do a great job of abstracting away all of this OAuth complexity, but as a developer, I should be able to look at the calls and understand how they work immediately.

Developers should be somewhat afraid of things that are black box implementations of anything, and while the MySpace SDK isn’t exactly black box, it isn’t intuitive either. It takes a real time investment to understand any call made to the api that involves OAuth. What’s worse is that it’s needless complexity. Twitter’s API uses tried and true authentication headers to prove identity. Easy, understood, you know what’s going on immediately and should something break, how you can roll up your sleeves to see what’s wrong.

Most developers who work on the MySpace platform won’t take the time to understand it because of the massive bloat attached to it. It’s too far gone now for any proper change with the MySpace API, not because it can’t be changed, but because there is no culture in place to change it.

Want developers to work and create for your platform? Get out of your own way.

The guys involved with Play! released 1.0 earlier this month, so I bundled up a OSX installer to place the commands in convenient places for mac users.

Check it out here:

http://driftlogic.net/play_framework

Most job ads tend to take the same format, who they are, what they’re looking for, what you’ll get in exchange. Those are the basics of posting a want, the three W’s: What we want, what you want, what they want. The better companies have shorter ads and general statements about technology (See: Freshbooks). Bad ads have long descriptions and very specific technical requirements (See: Just about any posting on Workopolis). Then, there are special cases of really bad ads, lets call these the star ads.

What’s really nice about douchey ads is they’re dead easy to spot. They usually include the words ‘rockstar’ or ‘ninja’ and have code placed somewhere in a prominent location. All code job ads are particular turnoffs (see: a crappy ruby ad). Ads that include code are generally self defeating, and potentially backfire if written poorly (do you really want to show that you can’t write code to begin with?). Most developers can read through a code post in C Syntax and pick out the important bits. Okay, you’re looking for ruby. Right, you were on the Today Show (so were these guys). Really, who doesn’t think that they’re a smart, highly productive, curious, driven, team player?

I get the concept of trying to challenge people in your job ads. Employers are trying to stand out just as much as job seekers in attracting talent, but ads like this don’t show the potential that the kind of workers they attempt to attract desire: Opportunity. Ambitious and curious employees want the opportunity to rise above or explore technologies and opportunities. Things like book allowances, conference reimbursement, and paid time for personal development go further than your smartly typed ad (this blog posting by 37 signals gives me employee stiffies every time I read it). Not because of the job perks, but because they show a culture of personal and professional growth within the company.

There’s also a special kind of job ad that serves as not only a total turn off for applications, but about the company as a whole. Lets call these, the challenge ads. Challenge ads think that they’re smarter than they really are and include a unique kind of hubris reserved for ‘rockstar ninja hackers’. Case in point found here.

From the job ad alone, they’re looking for a ‘Hardcore PHP’ developer. If that means that I fall asleep to postings by Rasmus and wake up chewing through extension code, then I guess that’s not me. I think developers should have broad interests, and I’m not alone.  There are some other general turn offs to this ad, from the massive, unattractive logo pushing the job description below the fold on every normal human resolution, to the biz speak description of the developer team. But the real winner in this ad is the method for application.

If you think that you ‘have what it takes’ to become a ‘Hardcore PHP’ developer, you’re directed to http://proveyourworth.net. Defying anticipation, the site is as big a turn off as it sounds. A large ninja graphic and XKCD comic set the tone of what’s to come. I’m not going to go through the ‘challenge’ presented, but effectively, you’ll be bouncing back and forth through URLs reading source and opening up firebug to look at request headers in a challenge worthy of level zero in The Python Challenge.

Sites like this do nothing to make accomplished developers want to join your company. If anything, you should treat developers in the same way as anyone who might be viewing your site. They’ve come with a task in mind, the faster you fulfill that task, the sooner they’ll be encouraged to get in touch about working for you. If you’re asking someone to buy into your companies vision, show them what that vision is, why they should be a part of it, and what rewards are there for people who decided help you get there.

(BTW: Web development already has a set of Rockstars, and 37 signals got there first.)

Google was the first really ’successful’ company to adopt the simple site approach. Yahoo was the big dog on the block with it’s dramatically complex presentations and homepage, exposing all of the information about the nuts and bolts of the machine along with the attempt to force feed users associated content at the search box and home page.

Intentional or not, Google figured out the one cardinal rule of web development. Users visit sites with a task in mind, and that task is often singular. No matter what the site or application, users don’t spend time exploring, unless your site keeps a tight narrow focus. Users who land on a site looking for information about racing will spend more time exploring your site if it has a focus on racing, less time exploring of racing is just one component of a multi-focus site. Search results have conditioned users to expect results to be single page only, with little related information if any.

Developers and designers have a great deal of trouble scaling back ideas to fit into this singular focus approach and filtering out the noise. Most of it has to do with the brainstorming at the beginning of the project. When an idea sparks, random thoughts are encouraged in brainstorms or while the idea is being developed. But before development begins, teams need to spend time performing a reality check, not only in regard to the scope of the development, but about what ideas are included.

The scope of the project to the first milestone is a great barometer of success. Ideas that keep development as tightly focused as the idea tend to produce better products and better code. Projects where developers are scattered, attempting to work on multiple facets of a system simultaneously are a good indicator that the project lacks focus. Attempting to narrow the scope during development is nearly impossible, and almost always results in missed deadlines and backwards development.

Successful projects focus on the idea most commonly found in development for social networks where releases focus on minor features and continuous integration and release. Plan schedules around minor features, not major ones. If a feature can’t be paired down to a series of minor releasable features, it should either be considered a separate project outside of the current scope, or be refactored before development begins. Even beyond this, each complete minor feature should be considered a full release. That might mean that you’re releasing new features each week, and honestly, that’s okay. Users adapt to incremental changes in a far more flexible way than large scale changes, particularly in the flow of your site.

Happy, focused developers tend to lend to happy, focused users and user experiences.

Mighty Quick Piadinas

Total cooking time from prep to finish is about 1 hour. Makes about 8 medium or 6 large piadinas, depending on thickness.

You’ll need:

• 2 cups all-purpose flower (You can substitue 1 cup of whole wheat)
• 1 1/2 tablespoons oil
• 1/2 teaspoon salt
• Water (keep some around, you’ll be adding this slowly)

Start by combining the flower, salt, and oil in a large mixing bowl. If you have a mixer and feel like using it, that’s great, if not, just get ready to start using your hands. Using a fork, start combining the contents of the mixing bowl. After the flower, salt and oil are combined, slowly start adding the water. You’re looking for the dough to be just moist enough to turn into a large soft ball. If it isn’t sticking together, or feels a little dry, add more water. If it starts to turn into soup, add more flower slowly.

After you have your doughball, take it out of the bowl and place it on a large lightly flowered cutting board, or counter, or whatever you have that’s flat and will take a good pounding. Start kneeding the dough, mainly with the heel of your palm. Smash it out flat on the board from four directions, then fold it back up and flip it over. Keep doing this for about 3 – 5 minutes.

Now that you’ve given the dough a good beating, form it back into a ball and let it sit on your cutting board. Now let it rest for 20 minutes. While you’re waiting, grab a large flat pan and place it on the stove. Be sure to keep it dry, no oil or butter.

When the dough has rested the 20 minutes, roll it into a large long log. Try to keep it as consistent in thickness as possible, and do keep it rather thick. Next, take a knife and divide it into sections. The larger the section, the larger the piadina will be when rolled out.

Before you go any further, turn on the heat under that pan we put on the stove a step ago. High heat is fine.

After the dough is divided, roll them into small balls and place aside. Now, you’ll need a rolling pin. If you don’t have a rolling pin, grab another large flat pan, and cover the bottom with flower. Take a doughball and roll it out as if it had four corners. In the beginning, roll four corners, then flip and do it again. After a few flips, you can roll allot more without flipping.

If you need to use that pan, place the dough in the center of your cutting board and place the pan on top. Now press evenly and firmly down on the pan, centered on where the doughball is. Then remove the pan, flip the dough, and do it again.

Through either rolling method, keep pressing until you have your desired thickness. You can keep piadinas thick and they’ll become slightly chewy, or if you make them thin, you can make them really crispy and great for dipping.

When you have one rolled out to a desired size, place it in the heated pan. When the piadina’s cook, they’ll bubble up in places where air was caught in the dough. This can actually be kind of cool in the final product, but if you don’t want this effect, take a fork and puncture all over the exposed side of the dough once in the pan.

Now watch your flatbread cook. If you want them slightly chewy, it should only take about a minute and a half each side. It’s cooked when you start seeing a few char marks on one side, just pry it up with your fork to check. When one side is cooked, flip and wait another minute. When both sides have that nice char, fish it out and place on a plate. Stack the piadinas on top of each other while cooking. If you’ve decided to keep these crispy, place a sheet of paper towel at the bottom of the stack to absorb moisture as you keep cooking.

Repeat the rolling and cooking steps until you’re out of dough. I usually roll out one piadina while one is cooking in the pan, so I get an assembly line process going.

These go great as sandwich wraps, or cut into sections and served with salsa. You can use them almost anywhere you might use a tortilla, or for a more italian experience, try serving with a small bowl of olive oil and some diced tomato mixed with parmesan cheese.

More info about the Piadina here:

Wikipedia

A few months ago I started looking around at the JVM alternative languages, Clojure, Groovy, the J’s (jython, jruby, ect.) and eventually Scala. I have somewhat of a classical computer science background. I started at a Java school, then moved over to a college that taught C in it’s first year courses. When I found my first job after school, I started developing in PHP and for good or bad that’s what I’ve been doing the last 4 years or so.

I like PHP. It’s everything and the kitchen sink mentality makes developers tend toward hodge podge code mostly, but there can be some really beautiful creations when you start using PHP version of reflection. But ever since I started working with Java again for projects at work, PHP feels like it’s missing the power of a systems language. Having to bolt on opcode cachers to deal with compiled code and the tacked on nature of using php as a command line language felt somewhat odd. Using pure Java is always an option, and Sun has done a good job of keeping the JVM up to date with new features and enhancements, but after enjoying the lose structure of a scripting language, it’s hard to go back to verbose development.

That’s where Scala comes in. David talks about how it’s somewhat difficult getting Java programmers to switch to something functional, and maybe that’s true. I don’t think that hard core Java programmers are Scala’s potential audience. Those crazy scripting guys from Ruby, Python, and PHP will feel right at home with Scala’s half functional / half object-oriented syntax. They’ve been dealing with choice and somewhat functional constructs for years, show these guys that you won’t need to start redeveloping in a another language when your app approaches a certain level of success and you’ll get them hooked.

Couple that with the hack that is Comet becoming the norm for web based apps that need push notifications and Scala’s actors become really attractive.

Stahl left Coke in 2002 to become the president of cosmetics giant Revlon. Jack was known for his marketing savvy and operational disipline according to the article, but ultimately failed in attempting to market the Revlon brand and left in 2006. “He didn’t know what he didn’t know” defines Jack Stahl’s leadership according to one quote from the article. That concept of knowing what you don’t is one of the keys of being a software developer. It’s one of the keys of being any kind of engineer.

Being an effective developer is even more than knowing what you don’t; it’s about knowing what is possible. Being in touch with what other people are doing, what technologies are evolving, how they’re evolving and seeing how others are applying them gives you an even larger set of ideas to draw from when given a task. Some consider personal development to be learning a new language or approach, but in reality need to embracing the concept of daily learning.

Daily learning for software developers is simply keeping up to date. Reading sites like Hacker News or Reddit Programming in addition to the blogs of notable developers, then taking that next step after reading about a startup or creation by finding out how it was done. In cases where the implementation isn’t available, take that problem and find out what kinds of tools are available to construct a solution.

I spend hours each week looking at open source projects, software libraries, methodologies, and ideas. Each one that I read about gives me new ways to implement projects I’m working on now and a chance to think about how I could have done things differently with things I’ve worked with in the past. It’s not required to fully understand how to implement those solutions, but if at some point you run across a problem where that tool would be easier and more effective to utilize than reinventing the wheel, you’ll know where to find it.

Knowing what’s possible is why developers need to communicate. Through personal blogs, comments, and conferences, we share our ideas along with our code. Those ideas are always portable even if the language is not. The very first time I saw anything about AJAX was at a PHP conference and at the time, I had no idea it was even possible. It changed my view about where web development was going. When I first saw someone demonstrate the concept, I had no idea how it could be implemented, but the idea was amazing. From that experience, I learned it was possible, and started to leverage the concept in designs as I learned about the implementation.

Developers tend to think of languages and processes as tools within their toolbox. Knowing what’s possible is like having an even larger selection of tools hanging in the garage, you might never need them, but you know where to find them if you do.