Yehuda Katz presents EmeberJS in Philadelphia

Thanks to Yehuda Katz for his talk on ember+ES6 for us non PhillyETE attending folks.

Here are my quick notes but definitely suggest catching him live or searching youtube to see him present.

Ember
- provides organization for your application
- fundamentally uses HTML, does not define its own way
- allows you to extend HTML
- focus on URL because it provides context, if your web app does not keep the URL as context it's not a web app.

Then he did a walk through of sample application, rapid paced intro but covered the highlights.

A good question from the crowd about what happens to all these server side frameworks (specific question targeted at Ruby). Yehuda's response for me was dead on, the front end is where things are going but not everyone is seeing it yet.  Leaving server side frameworks scratching their heads to define how they will better support this growing architecture.

My public response was that we agree and have already started the switch. As we continue to see this increased switch from web to mobile, building APIs and separating out the UI work has made life easier.  Everything as an endpoint has been a promise for a very long time and with the [Internet of things] happening all around us it is becoming a reality.

For myself transitioning between MeetMe where we got ahead of the mobile curve (2011 TC MyYearbook mobile growth) and at Stuzo where we are helping customers through the transition using frameworks like backbone, ember or angular seems to make sense for building responsive UI and mobile applications. We are building expertise on Angular as a team but I expect quite a bit of jockeying between these frameworks as they build their rockstar communities.

Thanks again to Yehuda Katz for sharing knowledge and talking passionately about his thoughts.

Geeks in the woods.

We recently held our second annual internal developer conference, Node 2.0 -- subtitled "Geeks in the Woods" in honor of the idyllic setting deep in the Poconos. While the first day and a half was more like "Geeks in the Dark," with only backup generators, glow sticks and flashlights to help us find our way through Irene’s aftermath, ultimately the event went off with only slight modifications to the agenda and provided a lot of value to the team. I have to admit that in our darkest hours, I was ready to call it and get back to civilization, but Gavin kept pulling us to continue – and right then, dramatically, the lights came back on!

Why do we hold this event?
Mostly to escape the one-hour time limit we generally maintain for office meetings. With so much going through our development pipeline at all times, it can be extremely difficult to find an extended period in which to work with the team as a whole, get everyone sharing ideas, and explore what we need to focus on to keep the team growing. So last year, Gavin spun up the idea for a developer retreat, and we jumped at the opportunity. Year One was Atlantic City -- when AC lost power! Year Two: Woodloch in the Poconos, barely post-hurricane but still mid-outages.

What do we do?
As this is only our second year, we’re still experimenting and trying to optimize the schedule. This year, the consensus was that we packed a bit too much into the three days, as we tackled four distinct areas:

1. Learn a new language.
On the first day, we brought in an instructor to teach the whole team a new language we don't use day to day. We believe that more focus on polyglot is valuable to the team and pushes folks to learn new ways of doing things, and more importantly, new ways of thinking about problems.

2. Hack-a-thon.
Can't talk about what we did, other than wow! I don't think this is something you can do very often, but it’s amazing how productive our team can be on such a short time frame. The pace was intense, but the way this event brought different folks together to solve problems encouraged a ton of knowledge-sharing, in many cases between people that rarely if ever collaborate in the course of normal work. This is definitely on the table for next year’s Node, and we have some new ideas for pre-planning that will make us even more productive in 2012.

3. Group Sessions.
One of the returning favorites from Node 1.0. Last year, we split into groups to come up with problems to solve and propose how to solve them. This year, we went a different route: each group built a pitch for a new product, planned their technical approach, estimated a project timeline, and presented their proposal to the whole team (including our CEO). Some good stuff I won’t reveal here!

4. Developer Talks.
Several developers prepared talks on a variety of subjects, from deep dives into recently completed APIs to more philosophical discussions of engineering approach. Even one of our partners found their way out to the mountains to talk about their company over lunch. The highlight for me was a session on test-driven development led by one of our DBAs, an accomplished speaker, which provided some great ideas we’ll be implementing moving forward. Overall, though, we learned that the hands-on sessions brought more value than just talking.

Do you talk about the business or just tech?
I gave a talk about leadership or management. Gavin explained how a focus on performance would lead to tangible benefits for the company. Jeremy reviewed product history and how it impacts our development process today. And Geoff gave insight into the business: where we’re headed and how. These are usually bookends to the day, and they serve to give context to the rest of the agenda.

How do we bring this to the office?
While we can’t always spare the time to hold similar events in the office, we do encourage the team to talk at local events, hold internal lunches to learn new things, and occasionally bring in external speakers to keep the knowledge flowing. More and more, we’re working as a team and not just a collection of individuals, and it’s been a beautiful evolution to watch.

So now I’m looking forward to Node 3.0: The Apocalypse Comes. Any feedback internally and externally on ideas for the event would be welcome!

CloudBees in the sky

I was recently asked to be part of a technical advisory board for CloudBees. The group included some great folks Eduardo Pelegri-Llopart, JJ Allaire, and James Gosling. Thank you Sacha and Bob for allowing me to participate with such a group. Besides meeting with the team and getting an overview of the plans I also had some time to play with both Dev@ and Run@.

Dev@ = Jenkins/Hudson/Nectar

Jenkins, recently renamed from Hudson, is the de facto CI system in the market. CloudBees provides a supported version called Nectar offered for on premise or as a service. I have been using it for years to help implement development process. Currently we use it on a daily basis to build for more platforms than I can mention - java being only a very small part of it. Today I wanted to start a build of one of my open source projects, one I have not touched in a 'VERY' long time. This project is currently hosted on sourceforge - https://sourceforge.net/projects/blue/.

After setting up my CloudBees account I added a Job and figured I would use it to generate my docs. Well it took me three times to get it right. The first time I did not set my ANT version properly, the second time I named my target wrong but then wala a working Jenkins Job in the cloud generating my documentation for Blue. I just wish I had this running when I was building Blue a few years back instead of constantly developing on my box and having to build ant tasks to push files to different places. Using Jenkins in the cloud (Nectar) could not be any easier and it would be great to see lots of open source projects participate. (CloudBees Todo: Allow making docs and distribution files publicly available).

Run@

While Run@ will be usable from dev through production I can quickly see how it simplifies life by reducing management of the development and testing environments. One of the challenges in building out a development process is physically connecting the systems together to create the outputs you are looking for.

A development organization can have 10's or 100's of developers implementing an equal amount of services with concurrent projects all needing to get out the door. This can be overwhelming to think about. I see Run@ and the concept of PAAS (platform as a service) as a building block for managing large development organizations and process.

Thanks again to the team.

Ryan - Great seeing you again, it has been a long time.

KK, Vivek, Harpeet - Amazing what you guys are doing both technically and fighting the fight to keep the community moving forward.

Spike - Glad to see you as part of the team bringing together the vision for PAAS.

Application Over TV

My venture into Application TV started a few months back when I was in search for a new TV. My goal was to buy a nice size flat screen and write some applications for it. Well I was quite a disappointed when not one provider had opened up their platform.

I defaulted to purchasing a Samsung 46" and while happy with the TV and the Netflix application everything else was lame. This all changed a few months back when this article on Programmable Web popped up on Samsung Free the TV. Since then I spent some time trying to understand TV development and have built out some initial prototypes for myself (and my kids).

In that time I have learned quite a bit about the platform. Shaping my own design considerations and development patterns. While finding my way to these ideas, I realized they seem to be at odds with how many of the existing applications are built. In my view, the current applications being built are not going to change our TV experience but here are a few thoughts that might have an impact.

1. It's only exciting if we integrate TV and Applications.

Why would you write something which takes up the whole screen and removes the TV experience? Why would facebook be a whole screen application?

These type of applications are as exciting as watching grass grow. Why can't I watch my show and update my status?

Another view type I have seen possible is the wrapped view. Perhaps some information context to the side and the TV show on the right. I can see this for integrating your stream view of the world into your current program. However, why wouldn't I just cozy up with my laptop and just let my eyes keep flipping back and forth. With the miracle of DVR I really do not miss anything.

My belief is that TV and Application are merged together. As you can see from the video, I wrote a simple Pong application which overlays the TV. The kids are watching a ball game while playing pong. This integrated view has been very popular with my boys and they have been very active in giving me feedback, finding bugs and generating a list of new games to develop - I need to get them writing code.

2. The remote must change.

I have not investigated the future of remotes but the life of the remote for the past 40 years must come to an end. I think folks like OpenRemote are trying some interesting stuff on the latest hardware but those platforms are not remotes. If you want to innovate with the remote you must start at the hardware level. Most recently I have switched from traditional mouse to magic mouse and now magic pad. Not being a hardware experience expert I am not sure what will work but it feels like the magic pad is on to something. With the flick of fingers I should be able to wave channels up and down or swipe four fingers and get a selection of channels I should be able to tap.

The other change for the interaction is support for multiple inputs simultaneously. Not to create a high end gaming environment but to allow some form of multiple user interaction.

3. I need access to the stream. Sorry Apple TV, Google TV and everyone else not owning Fiber to my house!

When building my little prototype applications I have came across numerous times where I want to interact with the signal. What is the closed caption text? What is the current channel? Where is there a face on the screen? Is there metadata I could tap into?

The reason I can not is because I am at the TV and not the cable box. The cable box has the best chance of winning this game. Perhaps they integrate Google TV or perhaps they expose the technology they already have. But folks like Samsung or Sony will have a tough time when the set top box not only gives me the overlay but access to the meta data.

Comcast, Verizon, Cablevision - what are you folks thinking? Verizon please learn from your mistakes with BREW. I believe there is a lot more to the relationships with the content providers and data providers limiting these folks from innovating. Until that key is unlocked, we will live in an Application in TV environment instead of Application over TV world.

I will be posting some hello world applications on the Samsung Platform for folks interested in development or wanting to share some notes.

Java and PHP

I have been talking to friends from both sides of the aisle about Java and PHP and finally had a moment to get some thoughts out on the topic. To start I have grown to respect both platforms. I find while working on one platform I tend to miss attributes of the other. However those attributes are not syntactic differences, but rather concepts that impact building applications, architectures and organizations.

1. PHP, the web request engine.

To have a singular purpose allows a greater focus on getting the job done and hopefully getting it done right. PHPs one focus on being nothing more or less than a web request engine is an example of the singular mind. In contrast java has baggage. I don't just mean the technical baggage but expectations required of developers. J2SE and J2EE are volumes and developers are expected to have an understanding of diverse technologies. Some suited for building business objects, others suited for building web applications and others for building the engine itself.

2. Java, objects from the start.

In interviewing developers and asking about past projects I always found a concrete difference in java projects and php projects. Most (close to all) PHP projects started as scripts which grew out of control, could not scale and then migrated to a php-mvc framework. In contrast all java projects start off with objects and a structure to the application. Java developers will ask what does your data layer look like?

3. Java. Type Suggestions (not safety) and Package Scope.

My reasons for liking type suggestions and package scope are not to build strict applications they are to build frameworks that can scale within an organization. When building in PHP I adhere to a strict separation of API and DATA/CACHING layers. This helps developers navigate a code base, reduce time to get people up to speed on projects and diagnose root cause of bugs. You might consider type suggestions bad form but I would be fine with function setThing( string $x ) where if we passed in an array for X it would work but emit warning. My interest in type suggestions is to know how to call a method. While documentation is standard in all projects things get missed.

4. PHP. Simple Controller.

As the controller will be the entry point for every web request it's best to be as lightweight as possible. To that end since PHP is built around the web request lightweight controllers are the norm. While there are always a proliferation of frameworks out there I suggest you build your own. You can do this two ways take one from out there and strip it down or start from scratch. The basic components are the autoloader, a naming scheme and of course the logger. Why I am against committing to an existing MVC framework? Because if there was one to beat them all it would have been done already. I have been asking myself why no single framework to rule them all for 10+ years. Years ago I thought it would be struts but it never reigned supreme. Optimizing a controller/MVC framework requires company specific details. Those details are technical, strategic and process oriented. There are so many options for what is a M, a V or a C that the possible combinations guarantee that everyone will disagree on the right combination. Perhaps Domain Specific MVC requires a deeper look.

Perhaps it would be easier to build web applications and development teams from some hybrid of java and php. To me it feels like a J2WE would be the distribution of choice for building web applications. Perhaps the J2EE Web Profile, but I think just a re-invention would not gain real traction as there are some new paradigms coming. Some PHP + Java hybrid would need to treat the cloud request as a primary citizen, maybe the only citizen. The cloud request being something which understands the web request and the self determination if it was human (browsing pages, submitting data), browser based (ajax ) or machine based (api).

Take your jacket and go home!

My new born niece was named after my grandfather Jacob Friedman. Steven and Beth asked if I would write something up about my memory of him.

Dear Hope,

"Take your jacket and go home!"

Your Mom and Dad asked me to introduce you to one of the people you
were named after, Jacob Friedman. For everyone in our family I try to
hold dear to me the one thing they said or did the most often, and for
your Great Grandfather it was 'Take your jacket and go home'. Strange
thing to remember as it does not seem that nice. You have to put a
lot in context to realize that it was in jest and love.

Great Grandpa Jacob was a man who lived and pushed forward in this world despite everything he went through. Being born and living in Poland before and during World War I and II could not have been an easy thing. The stories they all shared with me remembers the family living in one room which included kitchen and bed. I don't think they had indoor plumbing at that point. It was a very different world than ours today. Great Grandpa Jacob was married, before he married Grandma Sonia. He had two children. All of his family however was taken from him during the war and were killed. After the war he met Sonia in Berlin, Germany and fell in love and married her. I tell you this tragic story for two reasons
1. We should never forget our heritage and and the holocaust.
2. We should feel very special and lucky to have the life we have.
- From this part of his life I have always learned to persevere.

But there is a great second part to his life as well. In 1950 when your Grandpa Mike was three years old, Jacob and Sonia moved to the United States. They started with very little, but what they did have was community. They had Sonia's sisters and Jacob's friends. The greatest memories of my childhood are being part of this community. Though Jacob lived a hard life he kept Jewish tradition in his house. The singular most favorite memory of my childhood was Passover in Brooklyn. I just remember starting a seder in grandma Sonia's house with the immediate family. By the end of the night every friend and cousin was there enjoying each other.
- From this part of his life I learned family is what connects us, tradition is how we enjoy it together.

So 'Take your Jacket and go home'. It was simply his way of telling us to behave. We were a bunch of little kids running around, breaking things, fighting with each other and what not. You can't blame him. But those words stuck with me all my life and as I got older I started interpreting it differently. He could have said 'stop that' or 'get out if you behave like that' or just ignored us. But it was not meant in a mean way, why else would he tell us to take our jacket? He loved us! He could have said leave or get out, but instead it was go home. That was because he was a caring man.
- From this I learn it's always better love and care for others, especially family, no matter if we are angry or happy.

Your Uncle Rich.
PS. Your great grandmothers hair is still that big!

IFrame, Facebook, OpenSocial, Widget, Ringside

With Ringside Beta-4 release, by default we support 5 application types out of the box.

IFrame - Similar to the Faceook IFrame application and protocol.

Facebook - Plug your Facebook applications in! Deploy facebook applications with your own network. (example included by default is Footprints)

OpenSocial - Deploy open social applications right next to Facebook apps. Example includes Hello World written by Bill Reichardt and one from Last.FM. Bill published a trail map of how creating and hosting open social applications is possible.

FBML Widget - Use this widget on any website and have FBML rendered from anywhere, no application required. Bill put together a tutorial on using this capability - FBML on any website.

Ringside - Deploy applications directly inside the Ringside platform, we call them system level apps. All of the web features such as the community panel, login, registration, friends are delivered as system applications. The stylecheck application listed in the image is a system application.



In there are two open social applications, one written by Bill Reichardt and the other integrating a open social application by Last.FM.

Deploying your social applications with the Ringside platform enables a single application to be located on any website, community or social network. Users can access the applications anywhere and their data is portable across the web (the open web).

Rich @ Ringside