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.
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.
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!
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.
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, noone will tell you how to run things or which tools are best for the job, that’s up to you!
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.