scorchin

The patches to the Kernel are in review and can be seen here: https://patchwork.kernel.org/project/linux-input/patch/20201...

Congrats on launching!

Are you able to share further technical details on what you've had to do to get the speed gains you're describing?

For other mitigations to climate change, see Project Drawdown: https://www.drawdown.org/

As a client I've been happily using https://www.irccloud.com/ for the last few years. Does what I need: decent mobile and web client.

I've played with Teller and it's nothing short of incredible. The developer on boarding is super slick.

There's also webbit-rest: https://github.com/webbit/webbit-rest

Here's the previous submission: http://news.ycombinator.com/item?id=2446316

There are a number of people I know who have never touched Java and are being exposed to the eco-system through languages like Clojure and Scala and this kind of overview may be useful to them.

However, I agree that it's not worthy to be on the front-page of HN.

As of Java 1.5, generics were added. Before generics you had to cast every object you read from a collection. If someone accidentally inserted an object of the wrong type — possible in the OP's example code — casts could fail at runtime.

With generics, you tell the compiler what types of objects are permitted in each collection. The compiler inserts casts for you automatically and tells you at compile time if you try to insert an object of the wrong type. This results in programs that are both safer and clearer. So please use generics when using the collections framework.

I'm now going to briefly run through the examples provided in OP's post and update them accordingly.

  List<String> myList = new ArrayList<String>();
  myList.add("Second Thing");
  myList.add("Second Thing");
  myList.add("First Thing");

  Set<String> mySet = new HashSet<String>();
  mySet.add("Second Thing");
  mySet.add("Second Thing");
  mySet.add("First Thing");

  Map<String, String> myMap = new HashMap<String, String>();
  myMap.put("a", "Second Thing");
  myMap.put("b", "Second Thing");
  myMap.put("c", "First Thing");

For those looking for something more like Sinatra in Java, check out webbit: https://github.com/joewalnes/webbit

Here's an example of a simple Websocket chat server: https://gist.github.com/1421652

Disclaimer: It's an open source project that I have some commits to

Not sure about currently, but the (old) lead developer of FireBug left to join the Chrome team earlier this year[1]

[1] http://news.cnet.com/8301-30685_3-20080338-264/firefox-world...

> Our goal was that all the start-up booths would be staffed by developers at the start-ups, so you'd be able to find out what the culture and experience of their start-up was like, directly.

Yes, but not as much as I'd like to. I found it far too easy to get stuck in a slow-moving crowd or just wait in a queue to talk.

In the end I just stayed by the bar near the bar staff and talked to developers as they went to grab a beer. It seemed to work better and the devs were far more relaxed talking with a beer in hand. Same goes for outside when they went to grab a cigarette.

I'm a recent graduate and I attended the previous milkroundabout.

Let me start by saying that I've always hated recruitment fairs — you're treated like cattle and rarely get to speak to companies (read: HR departments) properly. I found it to be a similar situation with the milkroundabout event only instead of HR departments it was founders and developers.

I don't agree with "selling the brand" of milkroundabout as it will easily be confused with similarly named events/sites/companies. Instead aim to do guest lectures at universities on topics that are bound to get students interested.

If you're the ones with interesting work, why aren't you talking about what you do? Students already get told that they are under prepared for what working life is like and you can expose them to what you've done. You could easily compare this to what life was like at <insert safe boring company> before. If you're so inclined.

Pick topics that are interesting to the students that you want to attract. Then go on a tangent about start-ups, the culture, and the experience. If you show students what it's like to be in a start-up, they'll get involved and tell their friends.

In summary, sell them a better lifestyle than the usual suspects.

This is pretty cool, but my first thought after seeing this would be how easy it would make credit card fraud.

Thieves wouldn't need to provide a new address anymore, just one of these lockers and go pick it up.

On Aidan's own article[1], you can see that he's referenced work that's guided him in making this breakthrough. Hidden in the bibliography is a Dr Suess children's book!

Geisel, Theodor Seuss (Dr. Seuss). The Lorax. New York: Random House Publishers, 1971.

[1] http://www.amnh.org/nationalcenter/youngnaturalistawards/201...

The worst edited my CV before sending it to companies without telling me first

This is what happened to me when I first graduated from University. I showed up to my first job interview and they started asking me questions about my 4 years experience with Oracle and 6 years experience working on an open-source project that was critical to their business.

It left me shocked, depressed and seriously wondering if this is what it takes to get a job after graduating.

Luckily I had some other interviews at companies that I organised myself. Things went a little more smoothly.

I don't think Mozilla is short on cash.

In 2009 the Mozilla Foundation chalked up $104 million in revenue[1] from ties with Google, Yahoo, Yandex, Amazon, Ebay and others. I'd imagine there are some large donations in there as well.

[1] http://www.mozilla.org/foundation/annualreport/2009/faq.html

On discussing the 2% of respondents who found the Clojure community to be a problem:

...rather than simply bask in the awesomeness of the Clojure community, let’s ask: is it possible to make that number be 0% next year? What can we do to minimize those negative interactions? Are they caused by random misunderstandings, or are there just a few bad apples?

This is how programming communities should be discussed. This statement gives me hope.

Some of the newer televisions out have built-in HTML5 functionality and a few folks are already making games for them this way.

Currently they're using the remote control for input, but if they could access USB devices properly they could utilise the 360 USB dongle to take input.

I have evidence to the contrary.

I just went to a London Clojure User Group meetup on Monday. Stuart Halloway gave a talk on 'Radical Simplicity' which was well received. The event itself had 105 attendees and was free of charge. This was the first London Clojure User Group talk.

I wouldn't say it's losing steam. If anything, it's just getting started!

    template<typename _RandomAccessIterator>
    inline void
    nth_element(_RandomAccessIterator __first, _RandomAccessIterator __nth,
                _RandomAccessIterator __last)
    {
      typedef typename iterator_traits<_RandomAccessIterator>::value_type _ValueType;
 
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<_RandomAccessIterator>)
      __glibcxx_function_requires(_LessThanComparableConcept<_ValueType>)
      __glibcxx_requires_valid_range(__first, __nth);
      __glibcxx_requires_valid_range(__nth, __last);

      if (__first == __last || __nth == __last)
        return;

      std::__introselect(__first, __nth, __last,
                         std::__lg(__last - __first) * 2);
    }

Whenever a discussion on rearranging bits and bytes comes up, I can't help but recommend Hacker's Delight by Henry S. Warren http://amzn.com/0201914654

As far as the user-interface of printed books are concerned there is a very minimal, and understandable, set of features:

    - it boots instantly
    - has a high contrast and high resolution display
    - is viewable from any angle, in bright or dim light
    - permits fast random access to any page
    - provides instant visual and tactile feedback on the location
    - can be easily annotated
    - requires no batteries or maintenance.

Books do a great job of conveying static information; computers let information change. In my opinion, the local library will continue to exist as a place of knowledge if it can evolve to provide the tools to access changing/shared information. Otherwise, it'll just end up being a quiet place for students to work.

PlayNice.ly, a London-based startup has made gamification of bug/project tracking a core part of their product.

Not sure how successful they've been though.

Link: http://playnice.ly/

I only found out about Ganeti today and thought I'd post it here.

I'm currently looking over the docs and seeing how best to implement to play around with it.

Finding it particularly funny that back in 2009 the source code was moved off of Google Code and onto a hosted git server: http://code.google.com/p/ganeti/wiki/SourceCode

Sounds like you're about to invest heavily in a web-based company. The main application that customers will see your product through is a web browser.

You can easily write code for, and contribute to, these browsers. Whether it's for the rendering engines (gecko, webkit) or their open-source browser counterparts (firefox, chrome). Get involved!

Yup, here's the thread: http://news.ycombinator.com/item?id=2465002

As the vote count for comments has now been removed I feel the need to reply with "Yes! Please!", however in doing so would not add anything to the wider community.

So... I'd also appreciate any timings you could add to better understand where bottlenecks appear in this flow chart diagram.

The rest of the entries for PyWeek can be seen here: http://www.pyweek.org/12/entries/

On the whole you're on the right track, but I'd like to explain a little further about what you're doing and the possible long-term implications.

Feature Branches can become corrosive. Any changes made on the mainline will have to be merged with every feature branch. This is fine with small teams (< 3) but can become frustrating when you have a lot of feature branches or high velocity on your trunk/master. Long-lived branches and refactorings must be merged regularly to prevent merge conflict hell! A lot of this comes down to having disciplined developers.

Why develop on mainline? A lot of this comes from the non-dvcs days. It was expensive to make a branch/tag and they tended to be made when making a release. The beauty of keeping mainline up-to-date (commits once per day) is that you have a regular tracking point to revert changes back from on production. Instead of trying to remember which feature branch was deployed, you have a consistent (linear) timeline.

As you've said this becomes beneficial when you automatically test and deploy your code. A lot of this is to enable best practices for when you decide to setup a CI server like Jenkins to run your unit/integration tests and then deploy automatically (maybe) on a clean run.

Regarding git, I'm going to assume that you've taught your devs enough to follow good habits to keep them sane. Many find that learning git takes a fortnight or so to fully understand. Still, it's always worth throwing a bunch of resources their way. In no particular order:

http://progit.org/book/ http://www.gitready.com/ http://book.git-scm.com/

For more on this kind of stuff and no doubt a better explanation, check out Continuous Delivery by Jez Humble and Dave Farley. Link: http://continuousdelivery.com/