[0] https://www.technologyreview.com/2007/10/15/223446/steve-fev...
498 karma · joined March 28, 2013
[0] https://www.technologyreview.com/2007/10/15/223446/steve-fev...
[0] https://blog.mapbox.com/behind-mapbox-studios-new-look-874c1...
The lake was fed by diverting water from nearby San Francisquito Creek. The university chose to stop filling the lake for recreational use in 2001 to protect the endangered California tiger salamander as the article notes. The lake was still sometimes artificially filled to support salamander breeding, but it was not maintained to a level suitable for (most forms of) recreation (though I still saw members of KA attempt to take a raft out on 1-2ft of water during a rainy week -- I think their raft was more full of beer than the lake was of water, though my memory is hazy).
The university has since removed the dam used to divert water to Lake Lag as part of a process of habitat restoration upstream. I'm not sure how that will affect the population of salamanders that depended on that water in Lake Lag, but I believe they also breed upstream and will have more sustainable natural habitat. Also, water from Searsville Dam just upstream from this project is used to irrigate Stanford's golf course, and that is cited as a reason not to remove that dam (the other reason is that removing it would change habitats that formed from the lake it created).
The school has sometimes turned off its campus fountains during periods of drought. They shut the fountains down for 2 years while I was there. During that same time I didn't see them shut off water to the golf courses though, and that consumes substantially more water than the fountains. They did restore water in the fountains for the weeks leading up to our graduation, and I can recommend grabbing a pitcher of beer or two from the CoHo and walking it straight down to the fountain outside the bookstore for a soak, if the school still allows it.
To summarize, if we are to infer Stanford's priorities based on how it has approached the complex dynamics around Lake Lag and its (former) tributary, I believe that would look like: golf course > endangered salamander > students.
It’s true that there are some optimizations done in the build step that benefit end users, and folks will probably (correctly) continue to choose to minify, tree shake, bundle + bundle split, eliminate dead code, etc. for serious applications.
But to be able to write a modern web app without having to npm install a single module would be stellar! And it’s becoming more and more possible. How do you teach someone how to write a JS project in 2022? I imagine it starts with, “Well, first you’ll need to install node and npm - that’s gonna run JavaScript on your computer but don’t mind that much for now. Now we’ll install some dependencies required to build your code…” and so on. It takes a while and many conceptual hurdles to get to the part where someone can run the code they wrote in a browser.
We’re conditioned to expect there will be a compilation step between our source code and the code that runs in a browser. That forces many decisions about how we structure our projects and the kinds of tools we can use to deliver the software we write. Minimizing or eliminating the reasons why folks might need that build-the-code step between the code they write and the code their users run opens up doors and new ways of writing and delivering software, and that’s exciting!
Think, for instance, what would it take to get something like the TypeScript type checker in Chrome’s devtools? A first step would be to adopt the type annotation syntax.
Compare the site to sf.funcheap.com which I unfortunately use to learn about things to do here in SF. Yes, it renders without JavaScript enabled, but the two pages take the same amount of time to load in my browser, and Funcheap still tries to load resources from two domains blocked by uBlock Origin even with JS disabled (15 with it enabled). Is that really any better? There are so many miserable experiences on the web, most made particularly maddening by poorly applying JavaScript in the hopes of driving conversions on some metric. This site ain't it though.
Sure, the first load could include the initial brush of content in its markup. In 2022, this is a trivial change to sprinkle onto a front-end.
Django was my first exposure to Web development also around the 0.96 days. I couldn't have found my way into what has become a career without the friendly folks in the Django channels. What an incredible resource for newcomers.
I remember pasting full dumps of my models.py files into djangosnippets.org with vague descriptions of problems I was having, and folks I had never met before patiently sorted through possible solutions with me. Sometimes they'd nudge me away from an approach or suggest an alternative framing but they never judged me for what was probably pretty ridiculous code, considering I had no idea what I was doing.
Thanks to all the folks involved!
To be honest, we use LESS fairly simply for the things it provides like variables, mixins, and nested selector syntax. We otherwise haven't had a need to make our stylesheets much more sophisticated. So when project planning came around, we didn't ideate much on LESS-based approaches, and I bet we could have and found an ergonomic approach there.
I'm happy to chat and compare notes about how folks have executed similar projects.
I’m a bit surprised Sphero is using Kickstarter for this campaign — they’re a large company now with access to plenty of cash, I assume. Pre-orders have usually been a part of their independent product launches (i.e. the products that aren’t Lightning McQueen), so I could see this as an extension of that strategy with a maker/hacker/DIY aesthetic. Crowds out Kickstarter and makes it harder for the smaller operations to get discovered though.
In general (and take this with a grain of salt because I don’t know robots, only familiar with Sphero’s history), I think Sphero accidentally positioned themselves super well for building out products like these. They started with a robot-in-a-ball. Literally a two-wheeled robot driving like a hamster in a ball. In order to support a user-friendly driving experience with the original Sphero, they invested in the accelerometer and gyroscopic sensors and the way they provide feedback to the drive system. So even when the wheels would slip inside the ball, the robot would detect the change in heading and adjust to suit the driver’s original intent. They mention briefly in the video how this RVR bot can hold its heading on bumpy terrain, and I assume that’s the same platform at work. It’s neat to me because this feedback mechanism sounds like the kind of thing that’s hard to patch onto a robotic platform produced at scale and get it right, to the extent that folks won’t bother. They kinda got that one “for free” by validating that folks will buy a ball, and it looks like it’s been a solid platform for other variations on driving robots. (But again, I don’t know much about robots. This could be standard practice for all I know.)
One plot the book explores is of some lower class intelligences that work their way into the noise of the simulations of wealthier intelligences. Their experiences are computed simultaneously but imperceptibly to the hosts, and appear as but noise in the simulations of the floors, walls, fountains, clouds and other environmental props that the hosts observe and interact with. They live lives as meaningful and filled with human emotion as the others but they’re computed in the space between.
I know it’s a bit of a leap to go from an AI learning to slip satellite imagery in the noise of street maps to simulated consciousness freeloading in the noise of another, but I think the themes are consistent. One man’s trash is another man’s treasure. The book really opened my mind to the thought that there could be so much more thriving in the things we think are noise in our fleshy bodies, and I think that’s thrilling. Imagine what it would take to completely look past the street map produced by that AI and only possibly see a detailed satellite image! No other interpretation makes sense. It would all feel entirely normal as you’d know no other perspective.
> In hindsight, we chose the correct trade off.
This is key, and I think it's almost something you have to blindly follow when going into the transition. It's a lot easier to justify the decision to incrementally rewrite in retrospect than it is to get excited about it in the process. I think more examples would help shift that.
[0]: https://heap.engineering/migrating-react-mobx-while-shipping...
[0] http://www.nytimes.com/2015/12/11/automobiles/faraday-future...
[1]: https://www.mapbox.com/mapbox-studio-classic/
[2]: http://store.usgs.gov/b2c_usgs/b2c/display/(xcm=r3standardpi...
The data attributes almost seem to be a way to invoke CSS styles as functions themselves.