Archive for October, 2009

Dev Days – Cody Lindley on jQuery

Cody Lindley (Ning)

coauthor of JQuery Cookbook, due out next month
Authored a pdf book of examples called JQuery Enlightenment

jQuery – Intro for Developers

Who uses JQuery?

35% of all web pages running Javascript are running jQuery. 1 out of all 5 sites.

What is JQuery?

- A Javascript library
- helps ealing with the DOM
- Simplifies DOM events and animations

JS Bin – a very cool tool that allows testing of Javascript and HTML.

Shows an example of coloring every odd row of every table on a web page in one line of JS code. Adds roll-over coloring with a couple of more lines.

Why use JQuery?

Helps simplify and speed up web development
Allows us to avoid common headaches associated with browser development
Provides a large pool of plugins.
Large and active community
Tested on 50 browsers on 11 platforms
It’s for both coders and designers

Where to get jQuery?

Download source from google code (moving to github soon)
Use a CDN

Concept 1: Find something, do something.
- use the jQuery function to find an element in a page, and then do something to it.

Concept 2: Create something, do something.
- You can create elements in the DOM.

Concept 3: Chaining
Can use a single jQuery wrapper set and statement to execute a sequence of methods.

Concept 4: Implicit Iteration
E.g. when we call add class it loops over every element contained in the wrapper set.

Concept 5: jQuery() parameters
First parameter – can be passed CSS selectors, HTML, DOM elements, or a function shortcut.
Second parameter – can pass CSS selectors or DOM elements. Tells the engine the context in which you want to search. Default is the document or body element. Important for optimizing JS to narrow search.

Overview of jQuery API
- Core
- Selectors – see http://codylindley.com/jqueryselectors
- Attributes
- Traversing – can manipulate text nodes with the content method.
- Manipulation
- CSS
- Events
- Effects
- Ajax
- Utilities

Put your Javascript code at the bottom of the page to speed up when it executes.

Shows an example of creating a jQuery plugin in 6 steps.

Dev Days – Joel Spolsky on Fog Bugz 7

Joel Spolsky – FogBugzz 7 (now with an extra z)

We help developers make great software. FogBugz is the platform.
Planning projects (wiki, feature lists, backlog), Managing projects (assigning and tracking, scheduling), tracking bugs (web reports, crash reports, screenshots), talking to customers (email, discussion groups). Launching a plugin called kiln which provides source control. Uses Mercurial for version control and also manages code reviews.

FogBugz manages different projects.

The idea is team members come in in the morning and see what they have to work on.

Create a new project.

Build a list of features you want to have.

You can assign an order (scrum concept of a backlog order – truth is you only need to order the next couple of weeks of work).

Can use the wiki to write a spec

FogBugz 7 has an “exhaustive” plug-in architecture. Shows Balsamic, which lets you mock up UI, so you can have conversations about UIs in the tool.

You set Milestone dates and assign them to people for implementation.

FogBugz has hierarchy for tasks, so you can include as much detail as you want. He tells his developers to break it down to 2 day tasks, otherwise estimates are useless.

THe tool can show you remaining tasks and hours, and probability of reaching a particular milestone on a date. You can see when each team member is going to be done and what the probability for each completing tasks at which dates. Data is coming from historical analysis of what each person has done in the past and what their estimates were. You tell FogBugz what task you’re working on as you work, and it tracks time. It runs a Monte Carlo simulation, giving a probability distribution. Article on Joel’s website about how that works.

Per user timelines – what will a team member be doing at any particular point in time by probability. Shows when a team member is likely to be blocked due to dependencies not met.

Version control is integrated so you can drill down into code checkins for a specific bug.

Kiln adds the code review feature on top of the version control. When you want to do a code review, it assigns it as a case in FogBugz. Then shows you code and you can comment on it.

Easy to add new bugs.

Plugin architecture allows custom fields and workflow customization.

Can manage mailboxes for a team – sucks it all down and then applies filters, using Bayesian filters that can be trained. Then you can have lots of individuals assigned to reading and responding to specific topics within a single email box. “Designed to be a heavy-duty email feature for customer service” so you can do things like define lots of keyboard shortcuts. Also can tag email.

Runs on .NET, 7.1 will run on Mono for Linux or Mac.

10 users $1899, Unlimited $9999, On demand, 25/user/month, $599 up to 150 users

Students and startups free.

Kiln – hosted Mercurial and code reviews, Now in beta. Requires FogBugz on Demand. Free during beta. $5/user launch price.

Dev Days – Scott Hanselman on ASP.net MVC

Scott Hanselman – ASP.NET MVC

Visual Studio 2010 Beta 2

ASP.NET MVC does not dictate which database is used for Models, so new projects open with an empty Models folder.

URL structure is a user interface. ASP.NET MVC sets up predictable urls by default – a structured convention.

MVC built on top of web forms ASP.NET > MVC > Web Forms. MVC programmers can use all the existing stuff, but there’s like a new vehicle – webforms is like a minivan, but MVC is like a motorcycle – you could kill yourself, but you can go a lot faster.

Pluggable view engines.

Shows haml – which uses indentation and significant white space to make code cleaner.

Now shipping jquery in ASP.NET and MVC – MS contributing to the open source project.

By default C# code is compiled but views are not.

DevDays – Rory Blyth on Developing iPhone Apps

Rory Blyth – (rory@rory.me) iPhone development

What do you need to get started?
- A Mac
- Are you sure?
- yep
- But I heard…
- you heard wrong

Besides a mac -
- the iPhone SDK
- learn Objective-C
- read Apple’s design guideline docs (they’re really finicky about how your app looks and performs) – not really guidelines – they’re laws and if you don’t follow them your app will get rejected.

You don’t need an iPhone to get started because there’s a simulator. If you want to deploy to your phone you have to have a paid developer account. What if I don’t have an iPhone? The simulator is your frenemy.

What are some of the rules?
- One user app at a time
- No background (user) apps
- Effect the appearance of multitasking – it’s amazing how much attention has to go to restoring state.
- Don’t be a little resource piggy – scrolling tables can take up 45% of cpu. Need to carefully manage memory.
- Gracefully handle interruptions

Where does the magic happen?
- In your sandbox
What’s in my sandbox?
- Your app bundle.
Can I play in other sandboxes?
- No
There is a url mechanism for calling other apps, like the google maps app, passing it a query string.

Native apps vs. web apps – what gives?
If you’re gonna buy an iphone you got it because of the capabilities – not just a browser. A web app will not give you the same level of hardware interaction and richness that the native tools do. Just go native. Do web stuff elsewhere (not sure I agree with Rory here).

He likens building iPhone web apps to connecting a VCR to your HDTV.

Objective-C
- Looks weird – based on smalltalk, but built on c.
- Get header files (.h) and source files (.m)
- Define interface – here’s whay my type is going to do, not the implementation.
- Protcols are basically the same thing as interfaces in .Net and Java.
- id – the “anything goes” type – if you don’t know what the return type will be.
- Posing – swap out an existing class with your own in a sneaky way. “Objective-C lets you blow your foot off”
- Categories – extend existing classes without inheritance
- Properties, etc.

Apple’s Dev tools
- Xcode is the free IDE
- Interface builder to build UI
- these tools are definitely old and weird (based on NextStep), but they work.

The simulator is somewhat limited – don’t have access to all sorts of things that you have on the phone, but it works ok.

In the iPhone world you only get one window – so don’t create a “window-based app” in xcode.

When you’re designing, read the guidelines, and when you have questions, go to your phone and find an app and see how somebody else did it. Because if it’s on your phone it got approved, so it’s a good model.

Objective C doesn’t really have garbage collection – you have to increment and decrement persistence counts for objects. Calls it garbage inspection. Lots of memory leaks in badly written apps.

Shows writing iPhone app with MonoTouch, where he can write iPhone apps in C#, which he prefers. MonoDevelop is the open source IDE.

DevDays – Joel Spolsky on simplicity and power

Stack Overflow DevDay 21 October 2009 – Benaroya Hall, Seattle

Joel -

How much we get interrupted by our computers that want us to make decisions – especially Windows, which wants to know whether we want to make the decision we just made?

Sometimes software makes you make decisions that are just stupid – like on Rhapsody where the only way you can search is to choose which index (artist, song, etc), unlike iTunes.

Can’t even turn your computer off without deciding from among six different ways.

The debate between simplicity and power – simple apps that are highly simplified and do one thing well, obeying the 80/20 rule, vs. the Powerful software with lots of capabilities, features, and options. Example: the Swiss Army Knife that comes with a saw so small that you can’t use it for anything, vs. the hardwood floor nailer that only does that function.

Features lead to choices. Choices are the negative side effect of features. Quotes the famous experiment from Stanford where they set up sample tables at a deli one with 6 flavors and one with 24 flavors. 60% stopped at the 24 flavors, while 40% stopped at the six, but the opposite is true of actual purchases. Book – The Paradox of Choice, by Barry Schwartz.

37 Signals advocated less choice, simpler apps in their book Getting Real. Do less than your competitors – solve the simple problems and leave the rest to Microsoft.

Every time you have option in a dialog box, you’re asking someone to make a decision. People don’t like to make decisions – e.g. look at Tools/Options in any big app. The only reason those boxes are there is so you can accidentally get one wrong, so your computer will behave strangely until you get a new one.

The end result is these decisions make people feel stressed out and blame themselves.

Why is simple so popular?
When you’re a two person startup, the only thing you can advertise is “simple!”

Everybody tells you they love the simplicity, but…
They’re surprised by what your version of simple doesn’t include.

At Fog Creek they’ve discovered that the more sales you have, the more features you have – because you have customers that are asking for features, and when you give them what they need, they like it. Everybody only uses 20% of the features, but everybody uses a different 20%.

Conclusion – Powerful software does sell more and make more money.

What do people care about? Specifically, your users.

Long tangent about all human motivation coming down to DNA wanting to replicated itself – your use case should be there’s a 22 year old student living in a dorm room – how will your software get him laid?

People want choices and features that support their work. When you’re a programmer on a team you think it’s important – you think the user thinks about the same things you do, which is completely untrue. The computer does not have the ethical right to set the agenda for users. You are not in charge of what your users do. You do not have the moral right to put up a modal dialog box – ever.

Good design is making decisions. When you make the right decisions, that is good design.

Definition of Elegance. Example of iPhone silent ring switch, vs. Nokia’s 4 choices that require menus to set. By eliminating two choices you eliminate all the mnus etc. Lots of choices are disappearing – Apple’s driving a lot of that. Elegant takes a lot more work – especially user interfaces. Example of Amazon 1-click. Worth doing – give people the power in a simple way.

Take-out or Dine in? Considering The Future of the Enterprise Portal

I am participating on a team that’s looking at candidate software for the UW enterprise portal. The software that MyUW runs on was written in-house here, back before the term “portal” was even used in this context, and it makes little sense to pretend it is cost-effective for us to continue to develop our own code when there are other platforms that are widely used and supported, like Liferay and uPortal. There are also new needs for a web platform that allows easy integration of related applications, most pressingly in the area of research administration.

That being said, I keep wondering whether the concept of an enterprise web portal even makes sense anymore. We are at the beginning of a time where, instead of turning to monolithic portal sites that centralize information access and interaction, people increasingly consume information and applications in smaller bite-size pieces, distributed across multiple locations and devices. Individual gadgets show up now in Windows and Google, while Apple calls them Dashboard Widgets. These small “mini-applications” are characterized as being quick to develop and easy to deploy, making for low barriers to entry for information providers and consumers alike. Perhaps the best current examples of this trend are iPhone apps, which have grown to encompass apps for access to enterprise information as well as games and consumer interests. One notable trend is the bundling of specific pieces of content, like ebooks, as individual iPhone apps. People are selecting a variety of methods of interacting with different pieces of information, such as text messages on mobile phones, rss messages flowing into readers, and text-to-voice phone calls, in addition to traditional methods such as email or desktop web interfaces.

I can imagine a world where, for example, a UW grad student chooses to run the Course Registration App on her iPhone, gets SMS text message notifications of Husky volleyball and womens’ basketball scores, gets messages from her faculty through Facebook, receives notifications of grant opportunities on Twitter, and has access to her research data and apps for interacting with it via a web browser on her full-featured laptop.

It is at least conceivable, if not a foregone conclusion, that the future of enterprise portals lies more in the direction of a distribution hub instead of a single site where people interact with all of their information and applications. I think of this as being analogous to a take out counter as opposed to a full-service restaurant. Perhaps we should think of the Amazon or the iTunes App Store as the models for the portal of the future, where we can find the app or piece of content we need, see what the authors (or distributors) as well as other consumers have to say about it, and choose to download the appropriate version for the platform of choice.

Has anybody else been thinking along these lines?


subscribe

Pages

Latest tweets

interesting links

What I’m listening to

October 2009
M T W T F S S
« Aug   Nov »
 1234
567891011
12131415161718
19202122232425
262728293031  

Follow

Get every new post delivered to your Inbox.