Didn't find them when I went looking, that's all. FWIW, FastSpring's checkout is also a redirect, but they give you some pretty flexible control over the markup and CSS so its quite simple to keep the branding consistent.
Since that Reddit list of best sci-fi books I have churned my way through 4 novels; all of them have been absolutely excellent (Armour, and three of the Hyperion saga [just started the last one])
I had a call from a recruiter once, asking if I would be interested in a Ruby on Rails position. I said no, that's not what I'm looking for.
She then asked me to explain what Ruby on Rails was, how it related to other technologies and was it popular because a lot of people seemed to be asking for it.
Of course I explained the best I could, to make the world a better place and all that, but it seems (as other commenters have pointed out) that there could be a real niche for techies to run a recruiting firm that know what they're talking about.
"but it seems (as other commenters have pointed out) that there could be a real niche for techies to run a recruiting firm that know what they're talking about."
I'd love to do that. What would such a company look like?
Far too many "Paypal killers" coming about which lack one thing that could actually help them usurp Paypal...international support.
Stripe, Weepay, Samurai - all look amazing, but it is SO frustrating to seem them all release their products and pretend they can challenge the likes of Paypal whilst disregarding the rest of the world.
I know people are promising international support, but are they really going to make the jump after everything gets all cosy with a US only audience?
I've recently deployed 2checkout (I'm UK based). It's not pretty and it's not fully integrated with an API, but it's damn easy, doesn't require Merchant accounts and people can pay you with credit cards or Paypal.
I did a university module in Prolog (for programming intelligent systems). Although I have not used it since, I always remember it fondly. It is a totally different paradigm to the Pythons/Rubies/Cs/Javas and really quite refreshing when you get in to it.
Unfortunately I now struggle to think of a use for it on a day to day basis.
I think Prolog still has a place in modern software development. It provides a natural way of carrying out a backwards chaining depth first search through a state space (good for game AI, planning and scheduling etc). Also constraint solving is a very useful feature built into most logic programming languages now.
Prolog pureists argue that the whole of Prolog can be used for applications, but I tend to take a different approach that integration of Prolog with other languages can help you to do the things its really good and you can get the best out of multiple languages.
I'm a logic fan so I like prolog a lot, though for many people admittedly its greatest attribute will be expanding the way you think about programming.
However for some problems you might want to go right to constraint programming as you mentioned if you need speed and ease of modeling. I like MiniZinc for many problems, or if you're interested you could try my constraint programming language (http://sabrlang.org) which is based on spatial and temporal logic.
One can have Prolog-as-a-service. The SWI-PL implementation has excellent webserver out of the box. We feed the Prolog database from some external sources, do the reasoning and expose results via dead simple JSON API. It Just Works (tm) !!
Same here, all University of Amsterdam CS students (informatics, AI and information sciences) took a compulsory course in Prolog.
Except I was lucky enough to have a use for it after uni (about two years ago), writing generators for various puzzle games. It's one of the tasks that has Prolog written all over it.
Prolog matches very well with the grammar formalism that we use (attribute-value grammars), since attribute-value structures with arbitrary depth and re-entrancy can easily be represented as Prolog terms and larger analyses can be constructed through unification.
E.g. the grammar rules are plain Prolog rules where one argument argument is a list that represents the right hand side of a grammar rule, and another argument is the left-hand side. The rule goals define relations between the RHS and LHS by unifying parts of the RHS structures with the LHS structure. For instance, the rule for np -> det, n is this:
grammar_rule(np_det_n, NP, [ Det, N ] ) :-
np_det_n_struct(NP,Det,N).
Where np_det_n_struct unifies paths between NP <-> Det, NP <-> N, and unifies some paths with atoms. Completing a grammar rule is simply a matter of unifying members of the RHS list.
This looks like the purpose for which DCGs are designed
DCGs are not really practical when implementing different parsing/generation strategies, where you usually want to be able to access categories easily (ie. not as Prolog goals). Also, once you represent RHS constituents as a list rather than goals, you do not need DCG's difference lists to maintain adjacency.
Also, why ... instead of ...
Since the rule identifiers are never used as goals. They are just for printing pretty parse trees, and to see which rules fired for constructing an attribute-value structure (e.g. rule counts are used as features in the disambiguation component). Rules match on category (remember, there is more than one way to construct on np), which is a type in the type hierarchy for feature structures. An av-structure with type np will be structured as a Prolog term with the functor np.
Btw. note that the representation above is only the representation that the grammar writer will use. For parsing/generation transformed terms will be used. E.g. during generation grammar rules use the syntactic head as the first term argument, and chart edges use the next unprocessed RHS slot as the first term argument. Both to make use of first argument indexing.
I did a module in logic and prolog for a CS masters and agree it's very refreshing. I actually got a lot more out of it as a language in the context of predicate logic (which I started hating but by the end really enjoyed).
I would second "cloud based" (cringe) saving and sharing. Whilst I'm personally not bothered about collaboration, I would love to be able to work on maps across multiple computers (with no Dropbox for local storage).
It's a dream to use, congrats on putting something so impressive together.
Saving maps online, sharing and collaboration is definitely something I'd like to add in the future.
But if I want to keep the offline editing capability (and I really do) these features are not trivial to implement. Synchronization and conflict resolution hell awaits...
