Saturday, April 27, 2013
Job scheduling components
There's whenjobs and Airbnb's Chronos, because apparently job scheduling with cron is too... 70s or something.
Thursday, April 18, 2013
Word tree
Here is a fun little tool that, given a text, does a lexical analysis on it and provides an interactive concordance. Very neat.
The future of Excel
An interesting article, the key insights being: Excel is important to a lot of people because it lets business people do the modeling, you hit a limit pretty quick, VBA is not the answer because it's underpowered, real programming languages are not the answer because the model isn't useful to the business person, there may be a path forward in integrating Python and other open-source tools directly into Excel.
Or, you know, adopt the Excel paradigm as one front-end for a larger open-source project; that could probably be done in Wx without a whole lot of bending over backwards.
Or, you know, adopt the Excel paradigm as one front-end for a larger open-source project; that could probably be done in Wx without a whole lot of bending over backwards.
Django architecture best practices
Well. 11 suggestions for Django architecture, anyway. I love this kind of article.
Wednesday, April 17, 2013
Disassemblers and decompilers
I bookmarked this years ago (the link changed in the meantime) and here it is: a list of disassemblers. I wish I had more time in my days.
Snowball stemmer language
Martin Porter, the creator of the standard Porter algorithm for stemming English, went on to create a more generalized stemming language called Snowball. There are lots of contributed stemmers. Definitely a tool for the box.
Static app/pages with REST API backing = new architecture
There's a good point in this article: for a very long time, the "basic" Website architecture has been the CMS, itself a growth out of the old "database-backed website" model I cut my own teeth on, Phil Greenspun and AOLserver and all. Now, we're moving towards an API-based architecture as kind of the default. That's interesting.
Sunday, April 7, 2013
What can I do for Mozilla?
Wow, this leads lots and lots of interesting places... Here are the places I found interesting.
- Network Security Services: C-language tools for working with security
- PHP client for Marketplace
- Build and automation tools in Python
- Mozilla's own sites, in Django, and some Wordpress plug-ins
- DXR source code searching and indexing, also Python
- General Mozilla development in a raft of languages
- Rust
Man. I wish there were three or four of me.
Saturday, April 6, 2013
Here's an idea
Open-source music.
No, no, hear me out. I'm a sucker for electronica, you see (currently I get most of my music input from RauteMusik in Germany; their "HardeR" channel is normally a decent stimulus for productive work). Since electronica is already computer-generated, it would be simple (hhahahaha) to write source code for it, plus maybe some samples, I said more distortion, and compile the thing into a finished piece.
With me so far?
OK, so the "source" to such a piece would be the various melody definitions, waveform samples, processing rules, and "orchestration" (the overall architecture of the piece) - and you could put that on Github to let people fork it, you see.
Wouldn't that be neat? Of course it would. It would be like the Toon-o-Matic except for sound.
No, no, hear me out. I'm a sucker for electronica, you see (currently I get most of my music input from RauteMusik in Germany; their "HardeR" channel is normally a decent stimulus for productive work). Since electronica is already computer-generated, it would be simple (hhahahaha) to write source code for it, plus maybe some samples, I said more distortion, and compile the thing into a finished piece.
With me so far?
OK, so the "source" to such a piece would be the various melody definitions, waveform samples, processing rules, and "orchestration" (the overall architecture of the piece) - and you could put that on Github to let people fork it, you see.
Wouldn't that be neat? Of course it would. It would be like the Toon-o-Matic except for sound.
Epiphany
I just realized my posts here break down into longer essays and single blurbs about posts. It's the single blurb posts that normal people shunt to Twitter, isn't it?
It's just that I don't normally think that way. I should write a little API checker that watches my blog posts and autotweets the single blurbs posts.
It's just that I don't normally think that way. I should write a little API checker that watches my blog posts and autotweets the single blurbs posts.
Web frameworks and architectural description language
I've been toying with Mojolicious lately, gearing up to get over my fear of complexity and jump in with some simple UI for some little projects. There's a great Flask megatutorial series I'd like to follow along with, reimplementing the various steps in Mojolicious. (See also this example blogging app in Mojolicious::Lite.) But "porting" a tutorial begs trips the usual circuit breakers in my mind:
Namely, a Flask webapp and a Mojo webapp are both projections of the same abstract webapp, and what I really want is to describe that abstract webapp in a higher-level language.
I should really just no longer call it Decl. I should just call it Hylaea right off the bat. [pause] Yeah, that name is pretty uncluttered! There's a guy in Paris calls himself Hylaean (tweets some interesting stuff, not a lot of activity on Github and it shows he prefers the MS ecosystem - a guy worth following, actually) but that's about it outside the Anathem Wiki, and "Hylaea" without the 'n' is free as a bird.
Anyway, there is a semantic abstraction of the notion of the webapp that can be expressed in Mojolicious or in Flask or in, you know, any of the thirty thousand other webapp frameworks out there, am I right? But the abstraction, at some level, is the same for all of them, it's just that by working in one or another stack or language you might be led in different directions in development due to the affordances of the environment (that's a cogsci term I find particularly apt here).
That stack/language/environment/ecosystem is what we call the architecture on which we're developing a given app - but the way we think about the structure of the app or program or whatever (because this obviously goes way beyond webapps) is some kind of shared semantic structure that I think is amenable to externalization.
Note, of course, that the specific description of a particular architecture or app is a kind of "skeletal form" - because it doesn't encode all the knowledge about a thing, it just identifies it and evokes the library of concepts stored in the (getting back to Hofstadterian research here) the Lexicon.
Meditation prompt: is there a difference between Decl and Hylaea? I kind of think there is. Decl is an interpreter in Perl for declarative structures, but remains a pretty Perly thing. Logic is still represented in Perl, for example. Hylaea might be the overall programming system or something. Let's consider this for a while.
Labels:
Decl,
Hylaea,
system architecture,
Web frameworks,
webapps
Wednesday, April 3, 2013
Iterated feedback through YouTube transcripts
YouTube puts up transcripts of English videos. Here's a guy who cleverly read the transcript, read that transcript, and so on, then did a little measurement of the results.
Interesting stuff.
Interesting stuff.
HN store
Cool idea: use HNN's API to find and present book links ranked and by novelty. You could do the same for other links mentioned. I'd really like to start getting into this kind of thing.
Subscribe to:
Posts (Atom)