Hmmm, JavaScript wasn't implemented by Microsoft when IE1 was released. It first appeared 1995 with the Netscape browser. Here, the JS-sources are shown within the page...
IE3: Hooray for JavaScript (at that time called JScript by Microsoft due to trademark issues), but apparently CSS support is only in its beginnings:
Then comes IE4. Basic CSS support is there, but not much going on otherwise:
Needless to say I wasn't able to login with all of those versions. I won't bother to show you screenshots of IE6 - IE8, I'm sure you can find some machines around that have those versions installed.
Oh well, the good old times...
; a basic application using the google app engine
; when this file is created it will create a class that extends
; javax.servlet.http.HttpServlet which can be mapped in the
; applications web.xml.
(ns helloworld
(:gen-class :extends javax.servlet.http.HttpServlet)
(:use compojure.http compojure.html)
(:require [appengine-clj.datastore :as ds])
(:import [com.google.appengine.api.datastore Query]))
(defn index
[request]
(let [items (ds/find-all (Query. "item"))]
(html
[:h1 (str "Hello World. There are " (count items) " in the database.")]
[:a {:href "/new"} "Create another one"])))
(defn new
[request]
(do
(ds/create {:kind "item" :text "something"})
(redirect-to "/")))
(defroutes helloworld
(GET "/" index)
(GET "/new" new))
(defservice helloworld)
; starting the application in a jetty.
; the original application is decorated by a function that sets up the
; app engine services.
(ns start0
(:use helloworld)
(:use compojure.server.jetty compojure.http compojure.control))
(defn start-it
[]
(do
(run-server {:port 9090} "/*" (servlet helloworld))))
; starting the application in a jetty.
; the original application is decorated by a function that sets up the
; app engine services.
(ns start
(:use helloworld)
(:use compojure.server.jetty compojure.http compojure.control))
(defmacro with-app-engine
"testing macro to create an environment for a thread"
([body]
`(with-app-engine env-proxy ~body))
([proxy body]
`(last (doall [(com.google.apphosting.api.ApiProxy/setEnvironmentForCurrentThread ~proxy)
~body]))))
(defn login-aware-proxy
"returns a proxy for the google apps environment that works locally"
[request]
(let [email (:email (:session request))]
(proxy [com.google.apphosting.api.ApiProxy$Environment] []
(isLoggedIn [] (boolean email))
(getAuthDomain [] "")
(getRequestNamespace [] "")
(getDefaultNamespace [] "")
(getAttributes [] (java.util.HashMap.))
(getEmail [] (or email ""))
(isAdmin [] true)
(getAppId [] "local"))))
(defn environment-decorator
"decorates the given application with a local version of the app engine environment"
[application]
(fn [request]
(with-app-engine (login-aware-proxy request)
(application request))))
(defn init-app-engine
"Initialize the app engine services."
([]
(init-app-engine "/tmp"))
([dir]
(com.google.apphosting.api.ApiProxy/setDelegate
(proxy [com.google.appengine.tools.development.ApiProxyLocalImpl] [(java.io.File. dir)]))))
;; make sure every thread has the environment set up
(defn start-it
[]
(do
(init-app-engine)
(run-server {:port 8080} "/*" (servlet (environment-decorator helloworld)))))
As a follow-up to my posting “Software estimation considered harmful?” I want to talk a little bit about seeing a software project as a combinatorical optimization problem.
Do you know the Knapsack-Problem?
Imagine you are living in Papua New Guinea in the rainforest. You want to trade some of your "cargo" (see Jared Diamond, "Guns, Germs and Steel") at the market in the next big city. It is a two-days walk and you have to carry your cargo in a backpack. You separate your cargo in different boxes. Each box has a different weight and a different price per item.
You can't take all your cargo with you, because your backpack would be too heavy. So you have to decide which boxes you want to take with you. Of course you want to take the boxes with the lowest weight (i.e. the lowest costs) and the highest possible price (i.e. the highest value).
Which combination of cargo has the lowest costs and the highest value for you?! (To be able to solve problems like these gave our ancestors an advantage in the process of natural selection and evolution of mankind).
Let us now talk about software projects. For each software project you have to answer the following questions:
Question number one is almost always fixed. Normally the customer knows in advance until when the software must be finished to be useful. Normally you can't change the delivery date. This means, that you have time constraints.
Question number two is almost always fixed, too. The customer has maybe planned an IT budget for a new system. Anyway, nobody has infinite time to deliver a product. So you have some kind of budget constraints.
The answer to question number three requires hard work, systematic analysis and intelligent thinking: You have to go and find out for yourself, what your customer really needs. I don't mean you should simply just ask your customers for his software requirements.
You have to dig deep to find out this:
Which combination of features has the lowest cost and the highest value for your customer? (To be able to solve problems like these gives a software company an advantage in the process of natural selection and evolution in the IT-business).
If you have a fixed budget and a fixed delivery date you better find out what has to be delivered to make your customer happy and successful. Your customer expects the best system that can be delivered in time and in budget.
To map this situation to the before mentioned Knapsack-Problem:
The time (working days) between the start and end of the project is your backpack.
The maximum weight you can carry in this backpack is equivalent to the mandays budget for your project. (Number_of_developers * Working_days) <>
And your "cargo" are the features you have to implement. Each feature has a cost (the mandays needed for implementation) and a value attached to it. The value can be difficult to define. Sometimes you measure the value of a feature in relation to its implementation costs. Sometimes you measure a feature on how much profit it will generate our how much cost savings your customer can achive. Giving features a priority to determine the value is often easier: If a feature has a high priority for your customer, this normally means that the value is high and vice versa.
This is the way how we see software projects. It leads us to a simple planning algorithm:
To get into the details, I have to write more Blog postings. Stay tuned.
