Thanks. I havent created any custom vim scripts, but I do run a fairly stacked vim which is also on my github page (https://github.com/guyht/vimrc). There might be a good script for Jade somewhere (I have had to fight vim a few times over it) but personally, I have not come across any that I really need.

Redis in particular is super awesome, have really enjoyed using it so far and its insanely powerful.

Yeah jade worked pretty well out of the box. I guess you could even say that jade in itself is so concise that you don't even need snippets. The only thing that really pisses me off about it is how it treats strings and embedded tags within tags.

Like if you wanted a paragraph tag and then wrote a few words and now wanted to include a link it requires a lot of extra typing and is fairly unintuitive, especially if you want words to go after the link.

I run this for jade:
https://github.com/digitaltoad/vim-jade

and this for stylus:
https://github.com/wavded/vim-stylus

Both of those are just for syntax highlighting and basic indentation support.

Snipmate is a plugin that lets you apply snippets to anything you want. You could type something like "for[tab key]" and it will output a perfectly formatted JS for loop and put the cursor at the most intelligent spot.

You can apply it to any language though. For example you might want to make one for "jadelayout[tab key]" and that would create a full jade html 5 layout file complete with a head section and page wrapper, etc..

I do like redis. I wrote a bitcoin price scraper back when I thought I could profitably flip bitcoins between networks (this was sometime last year) and used redis to keep track of like 8 different trading networks and a bunch of stat comparisons with calculations to determine if it was profitable (it was basically 1 step short of being a full trading bot).

It was a pretty cool introduction to using pub/sub with redis. I also had it outputting to the browser with socket.io and node powered both apps. I remember going away for the weekend and leaving my VM up to get a decent dataset to work with and was really surprised that it was running when I got home.

Edit:
Some other things I noticed missing from your vim repo that you might like.

Hook this up and it'll put warnings/errors in your vim gutter on file save based on the language of the file (really good with jshint):
https://github.com/scrooloose/syntastic

Snipmate
https://github.com/msanders/snipmate.vim

Snippets for snipmate (more up to date than the above link for the actual snippets)
https://github.com/honza/snipmate-snippets

Wooster what do you use redis for? I've read a bit about it but can't quite figure out what its purpose is...

I have a question about something that probably doesn't matter at all, but it's bothering me, so I'll just go ahead and ask.

The following code is truncated for ease of understanding. The goal is to create drop-down select menus of months, years, and states.

The defpartial functions are in a separate file from the defpage files. The idea I am building up has several instances where lists like this are used.

This is option one. The defpartial takes 2 arguments. The param-type calls the kind of list, and the param creates the id= attribute for the drop-down select menu. The function generates the HTML code and returns the drop-down, id attribute, and options. This is done using a condition procedure:

The second option calles the defpartials directly. The defpartials generate the drop-down select menu, id= attribute, and options.

So, which way is better?

I was originally doing option 1 then I got stuck and then started option 2. I found myself wondering if it was possible to do option 1 again because it was the classic no-machine-error, no good reason it isn't working like it's supposed to, and was returning a completely mutated object (which is like wtf, how?), my curiosity got the better of me and I started working on option 1 again and now it is working like it should be. So, now I am thinking that option 1 may be over-complicating things or even (shock), slower than option 2. Ultimately, I can't justify why 1 or 2 is better, so I am here asking if it matters at all.

I tend to use a block paragraph and then just use inline tags e.g.

The way I see it, I use Jade syntax for anything structural, but std HTML for formatting.

Socket.io is really awesome, has such potential and its super easy to develop with. Also, have you used backbone.js at all? Its a really neat client side JS framework that I started using for PkrSess. Its v lightweight but extremely powerful.


I use it as a query cache and to store session data. Another common use is to store statistical information. E.g. lets say you want to have a running total of the number of posts on your forum, it would be very inefficient to so a "select count(*) from posts" each time. A better approach would be to run the select query once, store the result in redis, and increment it by 1 each time a new post is made. There is the possibility for the number to get slightly out of sync, so you would probably run your select query once per day to make sure the post count is correct, but you are still saving a ton of query time.

I've looked at backbone, knockout, ember and angular. I came to the conclusion that all of them really suck in some way or another. I kind of feel like something big will happen in the near future in this area so I'm trying to just hold by with my own client side organizing methods for now.

I also haven't written any non-trivial single page apps (client side routing, etc.) so I haven't seen a massive need to explore more options. Even right now there's still not great support for full single page apps (pushstate doesn't work on all grade A browsers yet, etc.).

MrWooster, if you're using Redis (I have no knowledge of it aside from 10mins browsing the tutorial) as a cache; wouldn't it be better to use an in memory cache instead?

I see the performance gain in the example you used but that look up probably goes to disk doesn't it?

Read the FAQ on the redis site. http://redis.io/topics/faq

It is an in memory db.

ahh cool. thx shoelace

It can write to disk too but most people just use it for storing things in memory. There are more robust solutions available if you want a full fledged persistent db. Nothing wrong with using both together.

Does not compute :P

I hear this "how do we identify good IT folks" quite a lot. There's a trivially simple answer to it in my mind

In addition to Shoe Lace's reply... yes Redis is just an in memory data store. The reasons for using it over standard in app caches are 1) its built to be super efficient and 2) it can be shared across multiple applications and machines (an in app cache would only be accessible by that one app on that one machine).

Good precedural code also keeps data and operations on data close imo. You can pretty much do OOP in C
http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

Talking about databases (a topic I really should improve on given I have only used MySQL,Postgres and ZODB). If you would build some sort of poker software that has to handle boatloads of hand histories (smth like HEM or maybe the pokerserver itself) today, what kind of DB would you use for the HHs? HEM uses postgres but it feels like some other type of DB could be better for this. But then you'd probably have to interface with postgres et. anywys for statsdata and so forth.

I got JPS working a few weeks ago (finally) heres the main parts if anyone is interested: http://pastebin.com/nzx2Wk4n
Its using a standard Chebyshev (octile,diagonal, w/e u call it) heuristic.
tm is a TileManager and dm is a DirectionManager.

I like path finding a lot and so far I've implemented AStar(BFS,Manhatten,Chebyshev,Dijkstras and Euclidian) and JumpPointSearch using the above heuristics as well. But now I'm out of ideas and cant find anymore except for Depth First Search and Breadth First Search both of which look horrible.

edit: heres proof it works: http://i176.photobucket.com/albums/w...ointSearch.jpg

Maybe not for pathfinding but the next progression would be local search algorithms and genetic algorithms. Maybe solve N-Queens with both or something
Might be a nice idea to get "Artificial Intelligence, a Modern Approach" and read through the search chapters.

Genealogy is probably something to look into for path finding.

Love that book!

Please.... I'm all in:
http://www.amazon.com/Growing-Object.../dp/0321503627

this is great question. i'd like to know the answer too from a db expert

You're right that data-oriented might seem a bit like procedural programming... but I think there is an important difference, even if its a bit nuanced.

Imagine a factory with an assembly line... you can bring in efficiency experts to tell you that you can increase productivity if the workers have a wrench in each hand. Thats focusing on the procedure and that might be a big benefit.

But, its all moot if you cant get the raw materials into the factory fast enough to take advantage of your really efficient assembly line.

That's what data-oriented design is all about. Making sure you've always got a steady supply of raw materials.

Clojure seems pretty cool... but as you note, its built on the JVM, so you still have that limitation.

Anything that makes concurrent programming easier, its going to be a good thing. Like I mentioned, thats where the hardware is headed.

But like I also mentioned, thats only half of it. The other part is SIMD.

If you look at how GPUs are architected, they essentially look like a collection of *really wide* registers... like hundreds or even thousands of bytes wide. This is sort of where CPUs are headed too, and if you want to take advantage of that, you've obviously got to have a language that can handle it.

Actually, of the languages I mentioned, only CUDA is really specific to a platform.

For the future? Yeah, I suppose C-like languages seem to be it... if only because they match and can adapt to the hardware so well.

It was interesting there for a while when there was a lot of interest in making "Java chips". But again, I just think the direction that hardware design has taken has really moved past where the Java bytecode is .

What Intel was doing with "Larrabee" probably would have suited Java very well. It was all the massive concurrency but without the SIMD (hundreds or even thousands of Pentium cores on a single die). But in the end, they havent been able to get it to compete with what nVidia and ATI have been doing.

It really depends on what you want to do with the data; in this case the hand histories themselves. Picking the right DB is all about knowing what type of data you're storing, what you want to do with it and what type of traffic/load you're expecting.

jason,

what are your favorite books on programming? and how about specifically low-level stuff?

Touche. No comment on Logo/turtle graphics?

gaming_mouse,

hmm... its been a long time since I've opened a programming book... lol

Oh, but I know... I can definitely recommend this book written by a guy I worked with, like 13 years ago (he's gone on to be a lead programmer on the God of War games):

http://www.amazon.com/exec/obidos/tg...altimecolli-20

While the book focuses on 3d collision detection (a pretty specific subject), it also has a bunch of *excellent* chapters on low-level optimizations for modern hardware. In particular is a *double excellent* bit on the gory details of how floating point math works and all of the pitfalls that await the unaware.

This book is *mandatory* for any would be 3d-game programmers.

That is a very expensive book, $91 for a used copy on amazon but it looks so good >.<