Sign in
in
   
"It is the mark of an educated mind to be able to entertain a thought without accepting it."  -Aristotle

About Me

I am a co-founder of Notches, an early stage startup currently based in NYC. We are building a free, open reviews network that anyone can participate in and anyone can build on top of. You can find out more on our official blog.

Read more about my background.

Connect with me on...

Recent Readers

Flickr Photos

 

Browse by Tags

All Tags » AJAX » .NET » Software Development (RSS)
  • If you can read a file, you can copy it

    Raymond reminds us that there is no "Copy" access mask because copying is not a fundamental file operation . Copying a file is just reading it into memory and then writing it out. Once the bytes come off the disk, the file system has no control any more over what the user does with them. Something to keep in mind when designing your web applications. Once you send something to the client, you inherently give up control over what can be done with that information.
  • JSON and XML

    Back at the PDC, I mentioned that Microsoft chose JSON over XML in Atlas, its AJAX framework. The debate has reared its head again recently, prompted largely by Tim Bray's post . Tim says that JSON is great for its single intended purpose, "to put structs on the wire." Dare, who used to work on the XML team at Microsoft, say JSON is better than XmlHttpRequest because it helps work around browser security model limitations and is easier to program with . The cross-browser issues are a particularly big issue that people have tried to tackle in different ways - I mentioned before that Julien is using a Flash proxy to work around these issues , and I've seen other architectures which use a server-side proxy on the original server to handle the third-party request. The key here is that AJAX is not about the technology , but the experience. JSON may or may not be the "best" way to approach this, but the exercise at least highlights some of the limitations (and, to be fair, strengths) inherent...
  • notch.es is hiring

    Notch.es is seeking ninjas . If you're a rock star, give Corey a call. I'm reposting the two job descriptions here. Don’t want to spend the next six months working under florescent lights on a corporate PC with no Internet access fixing someone else’s five year old code? Would you rather help build the next Digg or Delicious? Here is an opportunity to work in an exciting, fast-paced, collaborative early stage start-up with lots of room to flex your creativity and help shape the product. We practice iterative development; pair programming and have short milestones. We are looking for self-starters who are not afraid to voice concerns, take initiative and drive major subsystems. Corey will be at BarCamp NYC2 tomorrow. I have to work in the morning but I'm registered and will be there in the afternoon/evening.
  • Managing Exceptions in Framework Code

    One of the long-running debates here has been the use of exceptions for managing workflow. This was especially fierce while we were working on the Javascript framework, but it has died down a little in the strongly-typed .NET world. The two major questions are: ... when should should you return false / null and when should you throw an exception? I've always been of the opinion that a method should only throw exceptions for events that are truly fatal. For example, a search method returning no results is not an exception. However, a method that internally uses that search method may throw an exception under certain scenarios if it was intending on operating those results. Others are of the opinion that everything should be thrown as an exception. The argument is that even something like no results should trigger exception-handling code, and the easiest way to do this is have the callee fall into a catch block. ( I would counter that, even in the catch block, you need to special case different...
  • Javascript Syntax

    I've worked with JavaScript extensively over the past few years. Actually, I would say I'm way too intimate for my own sanity, but that's another story. JavaScript isn't a true object-oriented language, because there is no real concept of inheritence and protection. Rather, every object is just a hash-table, where the keys are pointers to either a method or property or object. It actually proves to be quite powerful - declaring and repointing methods at runtime is always pretty neat. I enjoy seeing others ( Darren , Andy ) dig into the possibilities of JScript, as Darren and Andy are. One cool thing, as Andy showed in his code, is that every property or method can be enumerated either by index or key name. Also, if you ever need to be able to resolve what method you're in, I wouldn't recommend using anonymous functions - use something with a meaningful name instead that you can parse and make sense of. Scoping is also quite interesting in JavaScript. First of all...
    Posted Sep 22 2003, 12:50 PM by Tim with | with no comments