St-Clock

That's an interesting take of the Python and Java relationship and although it complements well the landscape (with Jython, JPype, Pyjnius, and Py4J), I'm not sure what the need is.

(shameless plug warning) When I created Py4J (http://py4j.sourceforge.net/), I wanted to decouple the two ecosystems as much as possible so that both could evolve independently. There is no jni, no re-implementation of bytecode or interpreter, just plain sockets working on linux, mac, windows and most versions of Python and Java.

I believe this warning could apply to any young ecosystem or micro-framework (e.g., bottle). Could web applications written in Go, or to a lesser extent, node.js, suffer from the same shortcomings?

After working so much in Django, I've been interested in smaller, leaner solutions, but then, as my feature list keeps growing, I find I miss all the bells and whistles provided by larger frameworks. I did not think of the security implication before reading this article.

Auto123 - Montreal, Canada - 3 full time backend developers

== Who we are ==

We're a team of 10 professional but still fun developers building a new car dealership web platform that's going to power the web sites of our hundreds of clients across Canada.

We're working closely with a product team (marketing, design) and a production team (HTML programmers).

== Why it's interesting? ==

- Build a high-performance responsive web framework that is heavily customizable;

- Connect to 10 legacy DBs and render a page under 50 ms;

- Build a platform, work on API usability and interact with users to improve it;

- Work on the automated deployment and monitoring of hundreds of web sites and web applications each week;

- Improve products based on real UX studies.

If your pupils dilated at least once while reading, it would be interesting for both of us to work together :-)

== How we do it ==

- The devop team uses puppet, Fabric, nginx, and uWSGI.

- The backend team uses Django, celery, PostgreSQL, redis, memcached.

- The frontend team uses SASS, Compass, Backbone.js, and a heavily modified version of Twitter Bootstrap.

We love code reviews, daily standup meetings, campfire, contributing to open source, and paying for education (code school anyone?).

We hate long meetings, code without test, and incurring technical debt.

== Perks ==

- A table tennis table and some nerf guns (if that's your thing).

- Research and Development (we have a research grant with McGill University)

- A big office with wooden floors, brick and stone walls, located in the Old Montreal.

- Boring but important stuff like health insurance!

If you are interested, contact me at bdagenais@auto123.com with your resume and optionally, your github profile. Bonus points for bribes like github stars on our industrial repositories (https://github.com/auto123/).

Auto123 - Montreal, Canada - 2 Backend and 1 Frontend Developers

== Who we are ==

We're a team of 10 professional but still fun developers building a new car dealership web platform that's going to power the web sites of our hundreds of clients across Canada.

We're working closely with a product team (marketing, design) and a production team (HTML programmers).

== Why it's interesting? ==

- Build a high-performance responsive web framework that is heavily customizable

- Connect to 10 legacy DBs and render a page under 50 ms

- Build a platform, work on API usability and interact with users to improve it

- Work on the automated deployment and monitoring of hundreds of web sites and web applications each week

- Improve products based on real UX studies

If your pupils dilated at least once while reading, it would be interesting for both of us to work together :-)

== How we do it ==

- The devop team uses puppet, Fabric, nginx, and uWSGI.

- The backend team uses Django, celery, PostgreSQL, redis, memcached.

- The frontend team uses SASS, Compass, Backbone.js, and a heavily modified version of Twitter Bootstrap.

We love code reviews, daily standup meetings, campfire, contributing to open source, and paying for education (code school anyone?).

We hate long meetings, code without test, and incurring technical debt.

== Perks ==

- A ping pong table and some nerf guns (if that's your thing).

- Research and Development (we have a research grant with McGill University)

- A big office with wooden floors, brick and stone walls, located in the Old Montreal.

- Boring but important stuff like health insurance!

If you are interested, contact me at bdagenais@auto123.com with your resume and optionally, your github profile. Bonus points for bribes like github stars on our industrial repositories (https://github.com/auto123/).

Auto123 - Montreal, Canada - 2 Backend and 1 Frontend Developers

== Who we are ==

We're a team of 10 highly-trained but still fun developers building a new car dealership web platform that's going to power the web sites of our hundreds of clients across Canada.

We're working closely with a product team (marketing, design) and a production team (HTML programmers).

== Why it's interesting? ==

- Build a high-performance responsive web framework that is heavily customizable

- Connect to 10 legacy DBs and render a page under 50 ms

- Build a platform, work on API usability and interact with users to improve it

- Work on the automated deployment and monitoring of hundreds of web sites and web applications each week

If your pupils dilated at least once while reading, it would be interesting for both of us to work together :-)

== How we do it ==

- The infra team uses puppet, Fabric, nginx, and uWSGI.

- The backend team uses Django, celery, PostgreSQL, redis, memcached.

- The frontend team uses SASS, Compass, Backbone.js, and a heavily modified version of Twitter Bootstrap.

We love code reviews, daily standup meetings, campfire, contributing to open source, and paying for education (code school anyone?).

We hate long meetings, code without test, vendors selling things we did not build yet.

== Perks ==

- A ping pong table and some nerf guns (if that's your thing).

- Research and Development (we have a research grant with McGill University)

- A big office with wooden floors, brick and stone walls, located in the Old Montreal.

- Boring but important stuff like health insurance!

If you are interested, contact me at bdagenais@auto123.com with your resume and optionally, your github profile. Bonus points for bribes like github stars on my personal (https://github.com/bartdag/) or industrial repositories (https://github.com/auto123/).

I quit using Mercurial around 1.4 and was happily surprised by all the improvements in 2.8 (shelve, bookmark improvements, etc.). Martin Geisler's reply was both thoughtful and respectful, a rare sight in this debate.

I would have a hard time recommending Chef and Puppet unless you wrap your deployed unit in a .deb or .rpm file with pre and post install scripts.

Puppet is not really great at executing a sequence of steps because it is declarative: you can always express sequence as dependencies (e.g., reload nginx when file X has changed), but for fine grained steps (e.g., create a softlink for the latest version of your code), it's less convenient.

It's also slower than a Fabric script. If I want to revert to a previous version, I just do "fab revert myapp". With puppet I would have to rerun the puppet agent/change a manifest/change the version in my rpm repository/...

We heavily use puppet to manage our servers, but we rely on Fabric for deployment tasks.

Exactly. But to be precise, REST would be the equivalent of SOAP and the format described in this post would be equivalent to WSDL [1].

And then, we'll need a central location to store all of these API descriptors and UDDI [2] will be back with a vengeance.

[1] http://www.w3.org/TR/wsdl

[2] http://en.wikipedia.org/wiki/Universal_Description_Discovery...

This. With typical web applications, your request would wait until something times out and cascades back to the client (webserver, app server, db, etc.). This can mean waiting for 30 seconds or more depending on your configuration.

It's not an easy problem to solve elegantly too.

In terms of SaaS, we use:

    github (code review is the killer feature)
    campfire
    jira + greenhopper (no killer feature :-( )
    notableapp (so-so interactions with our designers)
    balsamiq (quick & easy mockups)
    crashplan (easy and cross-platform backups)
    google apps
    google analytics (we have a crazy setup)

I am currently looking into splunkstorm for our log analysis. We are using monit and mmonit (on premise) for alterting and monitoring.

For my open source projects, I use:

  github
  travis-ci
  sourceforge (for the mailing list. any suggestions for alternatives?)

Thanks for clarifying. I understand the decision better now.

How about an option (disabled by default) that allows self-signed certificate per fetched account, e.g., in the "edit info" dialog? I guess everybody would be happy with this one right?

I fail to understand how gmail accepting to fetch email from an account without any sort of encryption, but refusing to fetch email from my CS department which has a self-signed certificate can benefit me or make me more secure...

"eliminating extra steps (collecting/moving static assets)"

Interestingly, we extended the collectstatic command in many ways to perform minification, combination of assets, generation of sass and javascript variables (based on settings in python), etc. It's part of our deployment and if we were serving static files through django, we would still have to run a similar command.

I'm also happy that nginx is handling file uploads, aliasing, redirection, virtual hosting on different IPs and Ports with different access control, real ip extraction (when behind a load balancer), etc.

I'll be following more closely this trend of moving static asset hosting from a regular web server to the application container, but I believe that web servers like nginx and apache can do a lot more than just serving static files (at least, in complex deployment scenarios).

But you need a Mac to develop most (i)OS applications and I cannot imagine some of the more complex apps being developed on an iPad-like device.

This took down services like Fogbugz on demand.

Yes, but unless rpm/deb works with softlinks, it is not atomic right? Do you do anything before/after dist-upgrade or is it included in the pre/post install script?

For example, for our deployment, we rely on softlinks and uwsgi robust reload behavior to avoid losing requests. I've seen many devops who were using hg update/git update as a way to "deploy" (arg!), but I'm not sure about the behavior of deb/rpm.

I do not really care about the case or the iPad, but the footage is just stunning and worth your time.

The other big catch is randomness, which is often not understood by neophytes. If you try to find relations in sufficiently large data set, you're bound to find some that are "caused" by randomness. Tools like p-values are of little help when you fish for many relations (and not just one in particular).

This is so true. I've been mining mailing lists and framework documentation for my Ph.D. and most of my effort and time was spent normalizing the data. Once that was done, classifying content and linking concepts was relatively easy...

Well, I like this counterpoint too from the Google+ discussion:

"Sedat Kapanoglu: Technical innovation process on computing is too organic to find a single originator. Everything is derived from something else and that's what computing industry owes it's amazing progress in such a short term. Unix was from Multics. C was from B which was from BCPL. , and vi was from ex. We can consider vi itself as vim for ex from that perspective. I think there are no distinct thought processes for creating and improving. All creation is improvement and all improvement is a creation. We don't need to have a moment of silence for the father on a kid's birthday. Let the kid enjoy the day."

Would someone care to explain the downvote?

I agree with you, but he was using MongoDB and AFAIK, indexing is a must with this kind of db. Actually, I hope that he does not expect a big write load because he seemed to have added the indexes pretty quickly without thinking too much about it...

Just to reiterate, with a RDBMS with a decent query planner, indexing early is premature optimisation.

Yes, and Microsoft Research also publishes papers without any numbers on the axes of their graphs (e.g., number of bugs per component in windows vista). There is also a debate whether this can be seen as a significant contribution to science. Some thinks that it is, some don't think so.

In software engineering, these papers are still a minority and researchers (again, from Microsoft Research or IBM Research) often try to test their hypotheses or approaches on open data set (e.g., eclipse bugs repository).

Google just don't publish in SE venues so I never encountered this example. I'm sure they must publish more in distributed systems though. Btw, if Google is writing a paper on improving an aspect of Google Translate, I don't need their code, but I need at least the pseudo-code or the general strategy + their methodology and some intermediate data. Otherwise, it's not really a scientific contribution, just a tech report on something nice they did.

About Problem 1, I must stay vague, but the code I read was understandable. We tracked the time it took us to review the artifacts and since this is still an open problem (how to efficiently and fairly review artifacts), the process may change in the future.

To address the potential negative impact on the authors, I believe the papers who did not get a good review by the artifact evaluation committee just did not get a special mention. Since it is not possible to know who submitted an artifact and who did not (unless you got a mention), no harm is done for now.

The potentially negative impact on the authors' reputation was something that concerned me because I've been burned in the past by Ph.D. students not being able to use the tools I published and saying that my tools were buggy when they just did not know how to install Eclipse...

About problem 2, the conference organizers promised to keep the data confidential, but that might not be enough in some cases. For example, I would never show my interview transcripts to anyone, but there are some intermediate data that I could show and describe. We did not need to reproduce everything, we just wanted to see reasonable evidence that the approach described in the paper had been validated as advertised.

I'm not sure I understand the difference between problem 2 and 3. I must say that in my research area, I don't see many approaches and studies that are exclusively about proprietary data. Often, some part of the data/technique is publicly available or the approach has been tried on both proprietary data and open source data.

Overall, I think the artifact evaluation committee is a nice initiative and a step in the right direction. It needs to be carefully monitored and adapted to ensure that nobody gets burned for a bad reason though.

Thanks socratic for summarizing well the previous discussions! I was quite vocal against the obligation to release code if there was no incentive, even though I released the code of all the papers I published so far [1].

But to my surprise, the software engineering research community decided to try something new this year in one of their top conferences, FSE [2]. All authors of accepted papers were invited to submit their artifacts (data, code, video showing how the code was used, etc.) to the artifact evaluation committee. Two members of the committee reviewed each artifact and compared it with the paper. Papers that received a grade equal or above "meet expectations" received a special mention in the program [3].

Although the artifacts are not released to the public, this is a step in the right direction. If you are motivated to package your code for artifact evaluation and you get some recognition out of it, then the next step of releasing it is a lot easier. As a committee (I was part of it), we were afraid it would take hours and hours to just try to run the code that was submitted, but the authors really made the effort to package their code well.

[1] http://news.ycombinator.com/item?id=1868581

[2] http://2011.esec-fse.org/cfp-artifact-evaluation

[3] http://2011.esec-fse.org/program-details

"I think everyone understand that instructors aren't concerned about copyrights."

Well if you click on the "about" link on lectureleaks.com, you'll see that they only talk about copyrights. They do not seem to care about anything else... Incidentally, they have quite a lengthy copyright and license notice themselves... Maybe I should write one for my course.

"Are there any known instances of a lecture recording being used against an instructor unfairly?"

If you asked me whether instructors were sometimes treated unfairly by students, administrators or politicians, I would say yes. Having access to recorded lectures just adds a new angle of attack.

"I doubt doing things that could be construed as "out of line, incorrect, inappropriate, whatever" really improve your lectures in a significant and sustainable way."

I was actually referring to some ill intentioned people who would turn a joke, a simple mistake you made, or a controversial topic you taught against you. For example, teaching evolution is a risky business in some US states.

I am STRONGLY against this kind of service and I hope you will consider removing any recording that was not approved by the lecturer.

Otherwise, I want a recording of everything you have said while working. Actually, I want a recording of everything everybody said while they were working so my BigBrother TM audio processing technology can highlight anything that was out of line, incorrect, inappropriate, whatever.

I hope you understand that most lecturers/profs/researchers/people aren't concerned about their copyrights. They are concerned about their reputation and about what ill intentioned school administrators, students or politicians could do with these recordings. You just need one bad case of misuse of these recordings before some universities or unions sue the hell out of you.

I share your goal: education is good and the more people learn, the better the world will become. But if you start recording everything I say in my lectures, I promise you that they will be way more boring.

Maybe linear would be more appropriate than incremental as in: not all improvements in our lifestyle will have the same impact on our health. If you stand up and move every 20-30 minutes but you eat sugary and fatty food all the time, the improvement of your small breaks will be marginal in the long run compared to all the other problems you'll get. On the other hand, if you sit down all day but eat healthier food (good fat, more proteins, less calories, fibers), the benefits of this lifestyle will be greater.

Stress management and reduction also comes to mind (of course taking a small break and moving around can help that).

"Programs are pretty close to abstract maths"

For you and many people, yes. For me and many other people, no. I sometimes write math when I program, but more often, I manage. I assign roles and responsibilities. I orchestrate communications. I try to keep conflicts to a minimum. I often automate the way I think and I rarely think mathematically (that's how I wrote my Master's thesis and this is how I'm writing my Ph.D. thesis. I mean, the programs behind the theses).

"because the tools you use shape the way you think."

Yes... When you are starting to program or when you haven't been seriously exposed to other programming languages and paradigms, you are right. But I think I've been exposed to enough of these and made a conscious decision. For example, to me, prolog was immediately natural during my bachelor degree, but haskell felt more constrained.

Still, if I was primarily writing code in Lisp or haskell, I hope my pseudocode would be different. Otherwise, it would be quite a waste of time translating imperative programming to functional programming.

It's funny this came from SICP's authors because I always found that Lisp was harder to read/write than languages like Python which look like English.

I'm not saying one is better or that one is easier to maintain than the other, just that Python is really close to the pseudo-code, design notes, and specifications in English that I write. Not just logically, but syntactically.

In Java, I used to write some pseudo code in comments before attacking a particularly difficult method. I rarely do this in Python now.

Still Lisp can be closer to English than some Perl one liners :-)