joeroot

Echo this, they went out of their way to come through for us in an emergency. Fantastic service.

Vice is a fairly compelling case. They started with trashy "Do"s and "Don't"s, and now have reporters embedded within ISIS.

or Forego! https://github.com/ddollar/forego

Enough to get by! I worked on this throughout university, and now at my startup. I was slightly blasé however! The corpus is tiny (173 episodes: http://www.chakoteya.net/ds9/episodes.htm), so a topic model is unlikely to yield anything valuable. There are probably around 10-15 arcs, and simple clustering could be better -- but this is purely hypothetical. In this case, it's simply curiosity.

If you're interested in tools, Mallet (http://mallet.cs.umass.edu/) is a fairly good place to start, and the original LDA paper by Blei, Ng & Jordan (http://machinelearning.wustl.edu/mlpapers/paper_files/BleiNJ...) is a great academic starting point.

I see, apologies! I thought you had pulled in all episodes with a score > 7.

I wonder how easily arcs can be identified. I'll try running the transcripts through a topic model this evening.

I like the idea, however I'd disagree with the heuristic used. DS9 was really the first Star Trek series to introduce story arcs, and as such, skipping the wrong episodes leads to a confusing experience. I'd argue that in order to avoid missing out on important chunks of the arc, hand curation is really the only viable option (maybe text-clustering of plot narratives might work?).

Personally, as a huge DS9 fan, I think that you should watch every episode. Each episode adds colour and depth to the series' characters, and in my opinion makes it the most rewarding Star Trek series.

Streak (http://www.streak.com/) has been a good start for us. Upsides are that it's flexible enough to match most pipeline progressions, exports to CSV, supports mail merge, and allows you to easily track emails.

Our main issue has been that in person meetings and calls are difficult to log and keep track of, and as we've progressed towards those its become less and less useful.

If most of your interactions happen via email however, Streak is a great flexible (and currently free) tool.

Right now no. We use intuition to extract these. We're taking notes though!

Definitely. You can sign up without Twitter, it might just take a bit longer to get to the bottom of what interests you!

When you signup we spend some time trying to understand you by exploring your Twitter profile (followers, links, retweets etc.). Once done, we either recommend you an article from a curate pool of articles which we've come across before, or by browsing sources we think will have interesting content which you might not be looking at already.

We then send you an email with a link to the content and an explanation behind our reason. If the user replies or reads the link, we keep going. If they don't we stop! Ultimately to do this well, we want to have a conversation with the subscriber (almost like bibliotherapy).

For example, were someones Twitter data points indicative of an interest in Programming Languages and Education, we might send them http://worrydream.com/#!/LearnableProgramming, with a brief explanation on why. If they reply saying they don't like long form, old content, then we'd make sure to adjust the next article accordingly. Hope that helps!

Cheers Gigablah!

He noticed. 3 years of lurking down the drain.

No. We go through a user's followers by hand; identify common influencers and interests; cross reference these against interesting content from a range of sources. We will eventually look for scalable aspects, however right now we're trying to figure out what works best on an individual level.

Hey spindritf, good point. That was terrible copy. We've updated it to hopefully make more sense. We'd like your Twitter handle. This seeds us with our first few data points!

Hi sarreph. We hope to delight by understanding what each individual likes. From out initial testing, we've found that our first article is a pretty good starting point for tech "people" when we use their Twitter markers to inform us. From there we get a lot better if the user offers us valuable data points - either by reading the article or even better replying to our suggestions with feedback.

We'd all become tried of algorithms claiming to know who you are. We wanted to take this back to first principles and try to understand what captivates people.

Hey I'm one of the creators of Delight.

We're using Twitter as a starting point. We hope to work out what makes you tick, but ultimately that will only come from a conversation with you - thus why we've chosen to individually curate and pick content for all our users by hand.

If you pass us on any more info by clicking on "Tell us more", we'll use that too.

This highlights how "good" programmers are simply those who are most able to think like a computer. The article's language further reinforces this (perhaps intentionally), e.g. the reference to "compiling" functions.

I find this contraint interesting - I don't know if computational thinking is a strength or a weakness. Increasingly, it seems that computational models occur naturally and therefore the ability to think in such a manner would have inter-disciplinary value.

If we deem it a weakness, then programming becomes a UX problem rather than language one. The lack of change both within and across programming paradigms would suggest that many don't believe this to be a fundamental issue.

Pact Coffee - London, Full Time Lead Developer pactcoffee.com

We're opening the world of small-batch, fresh roasted and better tasting coffee to a global audience, not just those lucky enough to live in Shoreditch. Join an incredible founding team and help the world fall in love with coffee again.

We face a huge array of creative challenges in tying together a physical product with its digital counterpart. In doing so we’re looking for an experienced Lead Developer to help confront these as part of a great founding team. This requires a strong technical knowledge (especially in Ruby), a creative approach and the ability to work with the right languages and tools for the job. You will be joining the team to lead on all things tech, and as such, we’re looking for a generalist with Ruby experience, who will both guide and work on features and tools across both product and operations.

Generalist: Our stack is currently made up of Postgres, Rails, HTML, CSS (+ SASS) and JavaScript. Due to the challenges we face, this list is constantly growing and evolving, and we’re looking for a Lead Developer who’s comfortable in our current stack, but has the technical breadth and knowledge to change and move things forward as our needs develop.

Creative: You will help define product direction and be the voice for technology in the room. We want to re-approach classic e-commerce challenges in innovative and exciting ways. Be it applying cutting edge research to make sure people get the right coffee for their palette or experimenting with Arduinos and electronics to make sure they never run out; a strong technical background combined with an ability to think creatively are essential to us fulfilling that ambition.

Technical chops: You will be leading on forward thinking solutions which will likely push you into areas unknown! You’ll need to be comfortable with the stack we already use whilst also being able to pick up new skills and tools quickly in order to lead the team forward.

Product: You will help define our product roadmap, speak to customers and lead on the implementation of user facing features. You should feel comfortable in proposing and validating ideas before going ahead and building them out yourself or with the team. Once those features are live, you should be at home making data-based decisions about their future direction and flaws.

Autonomous: Though decisions are made as a team, you’ll be in charge of making sure we deliver on all things tech. As a small team, everyone needs to be comfortable working together whilst also taking individual responsibility and ownership for their area. As an e- commerce company, tech sits at our heart and as such your role is mission critical to the success of the business. You should feel comfortable with this. Ultimately as the company’s technical voice, no­one will tell you how to run things or which tools are best for the job, that’s up to you!

Interested? Email [email protected]

You'll never reduce Ruby to a pure grammar, there are too many ambiguous cases - my point was simply that it covers a subset which incorporates almost all common idioms. As far as I am aware it is one of the few openly available, non-trivial attempts to do so and thought it might be of interest.

I came across this issue when looking to build a stripped down Ruby interpreter in JS last summer. A few attempts have been made at defining its grammar, though with each new version the task becomes more and more challenging.

If anyone's interested, this definition of Ruby 1.4 is pretty good: http://www.cse.buffalo.edu/~regan/cse305/RubyBNF.pdf

Thanks for the blog post, I hadn't seen that before. As I said before, these things are subjective. In my opinion, the prototype model is too far removed from the classical object model to ever teach effectively with it. Primarily, my dislike of it within a classroom comes from the fact that it demolishes any chance of real typing. I think this is a serious issue when teaching children, both from a pure CS stand point and from an engineering principles stand point. It may make life easier for some programmers, its quick and light, but for teaching I think its inappropriate. I don't believe that in using it, the student gains no real insight into either CS or engineering. That being said, I'm no prototyping expert, so any counter argument would be informative!

The first language decision is always a tough one. Having spent the past few months teaching programming to school children part time, I found that you're often weighing up a number of considerations.

1) You want a language/environment which encourages creativity and offers visual feedback as a reward. This is where Brett Victor's demonstration becomes remarkably powerful. Instant feedback is important not only for the creative process, but for maintaining interest. Some children will never enjoy programming, but for those who will, how can you excite them? Languages such as JavaScript can be a good tool for this. Children spend most of their time in an IT lesson playing web games when your back is turned. Teaching them how to make those games helps foster an interest, and JS is a good language for doing this.

2) Do you want a language which teaches the basic building blocks of CS, or do you want a language which is of practical engineering benefit? You could argue that functional languages such as Haskell encourage children to really think about what computation is, or conversely you could propose that teaching JAVA prepares them better for the real world. Both have benefits, striking a balance is difficult. Deciding what's important can often be subjective: functional or OO, strongly or weakly typed, concurrent or not? There are so many factors at play that no-one will ever agree on a perfect learning language.

3) Simplicity of syntax and semantics. Wrapping your head around abstract concepts can be a challenge when young. Maybe Haskell's functions are too unimaginable to grasp, or Smalltalk's object model too mired in strange syntax. Is a type system containing Integers and Floats meaningless to a child who still finds fractions puzzling?

4) Finally, compiling and debugging are pains which few children are going to endure without losing interest. The requirement for code to run within the browser, I believe, is paramount: no installation, no mangled libraries and dependencies. Instead it can be run on a school computer just as easily as it can at home. Codecademy has done this really nicely, and it looks like John and his team at Khan Academy have done the same.

JavaScript ticks a number of boxes in my opinion. The number of tools and libraries available means children can build interesting, visual programs. Functions as first-class citizens helps introduce students to concepts within CS, and execution within the browser is a huge benefit.

Nonetheless, I don't believe it has it all. Its object model makes the teaching of basic OO concepts a nightmare. Its untyped and furthermore its type coercion can cause strange behaviour (this IMO can be extremely damaging; things work then all of a sudden they don't). Operator overloading is odd. Its just too quirky! Personally I don't believe it is an appropriate first language. It does some things nicely, but I believe it leaves itself open to a lot of bad habits if left unchecked. Ultimately I believe a first language should enable the student to pick up any language they want thereafter, and feel comfortable within it. Primarily it should teach pure concepts, not syntax and style.

Shameless plug, but having reached my own personal conclusion I decided to write my own language for the browser as an MSc thesis (http://joeroot.com/wardrobe/try/ | https://github.com/joeroot/wardrobe). Its still far from complete, but I think it serves as a demonstration of what I feel is important in a language. I like many was inspired by Brett Victor's talk, and thats the eventual, unmet goal for the environment. But for now my focus is on the language and implementing it within the browser. It is strongly typed (but fewer types), has first-class functions alongside a pure OO model, and less syntactic pluralism to name a few of its traits.

As I said before however, programming languages are a hugely subjective topic, and I think John's project is a big step forward. Personal experience of teaching children would suggest that this looks like a far more involved experience than what is currently available.

Thanks a lot for these - been looking for a solid set of resources on this for a while.

Does anyone know of a solid Ruby interface for this? When I tried using it for a recent project I had a lot of problems getting the Gems to work on OS X. Other than that I've head a lot of praise for it...

Thanks so much for this! Really helpful.