Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
>300 subscribers
>300 subscribers
Share Dialog
Share Dialog
I used to not be a big fan of frameworks such as Rails (Ruby), Django (Python) or Cake (PHP) for two major reasons. First, the frameworks did not seem all that mature requiring attention to patches and upgrades and raising at least the possibility of winding up on a “dead” branch. Second, the frameworks seemed to add a lot of overhead (e.g., in the ORM parts) so that you would need more hardware and were less able to handle traffic spikes. But I am slowly coming around to a different view. The major frameworks are clearly maturing and are in sufficiently wide use to assure ongoing support. More importantly though, we have the potential of moving framework based apps into the cloud much more easily. The reason is that with SQL abstracted away it is much easier to provide a cloud implementation of the data access. For instance, the models in Rails do not have to run through SQL – they could be implemented in a way native to a cloud infrastructure without breaking the Rails application. It is still early days on this latter point, but companies such as Engineyard and 10gen (USV portfolio co) are working on solutions that will allow framework based apps to scale easily. I should hasten to add that this means you should try to do as much as possible inside the framework and resort to custom SQL only as a very last resort, as that custom code will most likely have to be rewritten to a particular cloud datastore.
![Reblog this post [with Zemanta]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/http://img.zemanta.com/reblog_e.png?x-id=829f5530-67c5-45c2-be1e-3c5f86f29b3c)
I used to not be a big fan of frameworks such as Rails (Ruby), Django (Python) or Cake (PHP) for two major reasons. First, the frameworks did not seem all that mature requiring attention to patches and upgrades and raising at least the possibility of winding up on a “dead” branch. Second, the frameworks seemed to add a lot of overhead (e.g., in the ORM parts) so that you would need more hardware and were less able to handle traffic spikes. But I am slowly coming around to a different view. The major frameworks are clearly maturing and are in sufficiently wide use to assure ongoing support. More importantly though, we have the potential of moving framework based apps into the cloud much more easily. The reason is that with SQL abstracted away it is much easier to provide a cloud implementation of the data access. For instance, the models in Rails do not have to run through SQL – they could be implemented in a way native to a cloud infrastructure without breaking the Rails application. It is still early days on this latter point, but companies such as Engineyard and 10gen (USV portfolio co) are working on solutions that will allow framework based apps to scale easily. I should hasten to add that this means you should try to do as much as possible inside the framework and resort to custom SQL only as a very last resort, as that custom code will most likely have to be rewritten to a particular cloud datastore.
![Reblog this post [with Zemanta]](https://img.paragraph.com/cdn-cgi/image/format=auto,width=3840,quality=85/http://img.zemanta.com/reblog_e.png?x-id=829f5530-67c5-45c2-be1e-3c5f86f29b3c)
No comments yet