Disqus - Latest Comments for steveknoblock

Re: The Brutal Lifecycle of JavaScript Frameworks

steveknoblock — Thu, 11 Jan 2018 15:55:12 -0000

There's a balance. It's become very snarky to say just write code, but in the Perl community, the suggestion is to go look for a module in CPAN for something you have never written before, someone else more expert than you had done it, and its been in use, so bugs have been found, so why reinvent the wheel unless there is something new to address. The CGI module is a good example, everyone was writing their own hackish or copy and paste HTTP to Perl vars conversion subroutines of varying quality, and thhe advice from the Perl community was why try writing some tricky decoding when accurate decoding is already sitting there waiting for you?

That's not a framework though.

I've had experience where an ad hoc framework that was well thought out is simpler and easier to use than learning the concepts and requirements of a new framework. As service-oriented architecture grows, frameworks may be less valuable.

Re: The Brutal Lifecycle of JavaScript Frameworks

steveknoblock — Thu, 11 Jan 2018 15:44:41 -0000

Also, it could be many PHP sites were slow moving from jQuery to a framework until Vue.js was introduced and popularized.

Re: http://dev.farmfoody.org/codeigniter/index.php/profile/show/2.html

steveknoblock — Wed, 22 Apr 2009 20:08:23 -0000

Test

Re: http://dev.farmfoody.org/codeigniter/index.php/profile/show/294.html

steveknoblock — Tue, 21 Apr 2009 17:15:11 -0000

Hi Pablo!!!

Re: Discuss tinydb

steveknoblock — Mon, 23 Mar 2009 13:16:47 -0000

I agree with the approach of leaving read access open, but requiring some security for writing. A layered, human engineering approach, which wiki systems use could work.

New users can't retrieve data for a while.
Temporarily lock entries or access during a spam storm.
Rate limit, which increases the longer you use the db, assuming you are now trusted.
Maybe a "fico" score for users, representing how trusted they are by the system on some criteria indicating they are not abusing it. More access and features available to higher scores.

Anyway, just some thoughts.

Re: Discuss tinydb

steveknoblock — Mon, 23 Mar 2009 13:12:22 -0000

Tinydb is a really cool idea.

With the current security model, tinydb is perfect for _published_ content, which can be assumed to be public. The video or music catalog data is a good example of information where privacy is not required. Micro-blog posts have no expectation of privacy. I prefer that tinydb not be private, acting as a kind of "pastebin" or way to "pin" small pieces of information at a location.

The current model is perfect for a wiki-like system, which uses "soft security." It doesn't matter who knows the location of a piece of information or can change the data, if the data belongs to a wiki with content anyone can edit. I worked on a prototype some years ago where anyone who visited the site could edit and organize the content freely. The lack of security was intentional for both content editing and categorization, so tinydb would have been perfect.

I believe soft security and human engineering approaches to security would be a good fit with tinydb. New users (A user who has not been seen before by the database, perhaps by ip, or by giving each dataset its own namespace with a timestamp) of the db are not allowed to retrieve their data for a day. It would be an interesting experiment to discourage abuse instead of locking down the system. I've never heard of a db system taking this approach. The idea of exposing rows of a database to urls intentionally in as transparent a way as tinydb does is a pretty new idea as far as I know.