Skip to main content

Google Talks

By the way, gentle reader, in case you haven't noticed, I am running a series of talks at Google.

All of them can be found here. Updated July 2015: They seem to be available on YouTube, now that Google Video is a long forgotten service: They can now be found here.

Comments

Vinod G said…
It is great to see these wonderful talks! I quite enjoyed these, I hope you keep these going.
Jeremy Manson said…
Vinod: As long as I can find volunteers!
sri said…
Hey Jeremy,

- how about inviting Don Knuth to give a talk about software engineering? working with large programs -- like TeX. We need to have an archive of him -- I don't think he has given a talk like that.
- I know this isn't programming related -- Ron Graham (the great mathematician), is an awesome (and I really do mean awesome) speaker.

I really think that using this Google Video TechTalks you probably can invite a lot of the software luminaries (who work outside of Google) to give talks on programming in general (like Jon Bentley)...

Just my 2 cents.
Thanks for listening.
Anonymous said…
Hello Jeremy,

Very interesting talks.

Do you have a planning for the
talks to come.

What I'd also find interesting is
an ordered list of talks. For example ordered by the highest ranking with the highest number of viewers...this is what I look at when I have a spare moment and want to see a random topic a lot of others found interesting as well :-)

Kind regards,

Gian Franco Casula
Jeremy Manson said…
Gian --

Thanks for watching! I don't have a list of upcoming ones, unfortunately.

If you would like a list of talks ordered by popularity, then all you need to do is click on the pull down menu to the right that says "Sort by relevance" and select "Sort by popularity". For some reason, when you do that, the first video is not one of mine; I have no idea how that one got picked up, but such are the vagaries of search.
Anonymous said…
Hi there, I love watching these, some suggestions for interesting talks:

Simon Funk - Guy who came up with a fantastic algorithm for the netflix challenge.
Roberto or Mathias - on the super cool little project QLALR.
Guy Steele and his neat Fortress language he is working on.
Paul Graham on Arc (maybe we can get him to revile what he has so far)
Zack Rusin Crazy Ninja Hacker who works on Graphics and who's presentation are always fantastic both visually and technically.
Josef Weidendorfer or any of the Valgrind developers - The application that for some is the killer application on Linux.
Jeremy Manson said…
I'm glad you're enjoying them! I think they are a pretty valuable service. We don't really have a budget, so it is just people who either work at Google (so I can bully them into giving a talk) or happen to be coming by.

Having said that, I'd love to have any of these folks, but I don't know which of them (other than Guy) are going to be around the Bay Area.

I also love the near-recursion levels of Valgrind being the killer application on Linux. I think of a killer app as being *the* reason to use a platform. "Why do you use Linux?" "So I can use Valgrind" "Why do you use Valgrind?" "So I can write applications for (i.e., use) Linux"
Anonymous said…
I also love the near-recursion levels of Valgrind being the killer application on Linux.

I would have to disagree. I know of a hardcore BSD hacker who used to only run BSD everywhere, but one day switched to Linux. When asked why he answered Valgrind. A killer application is one in which you will switch platforms just to have it.

I also know of some windows devs who have around a spare Linux box for Valgrind.
Anonymous said…
Matthias Ettrich would be interested in giving a talk on QLALR when he is out in CA, what would be the best way to for him to get in touch with you?
Unknown said…
Hi Jeremy,

Do you know if Google Tech Talks can be shown in a company for a restricted audience and for
discussion purposes?

Cheers,

Gian
Jeremy Manson said…
@Gian - I'm not a legal expert and wouldn't claim to be. I would be surprised if there were any issues.
Tushar Goel said…
Hi Jeremy, Thanks for the talk. You have mentioned the link for all of your talks but it seems not working now. Could you please check and share some other locations where you put them?
Jeremy Manson said…
I updated the link. They seem to be available on YouTube.
Tushar Goel said…
Thanks Jeremy. I thought more videos on memory model.

Also, just wondering why you stopped writing? I saw last time you wrote in 2013. It is always good to have something from you seniors.
Jeremy Manson said…
@Tushar - there is one video on the memory model, but just the one.

I'll probably say that I stopped updating regularly because real life intervened:

- The frequency of my posts dropped radically when I got married, and that there has only been one post since I had a child.

- I have also only posted once since I doubled my non-technical load by taking on the management of the amazing Google Java Libraries Team, who are responsible for things like Guava, Dagger 2, Truth, and a number of other libraries that everyone should be using.

I have a lot to say, but not much time to say it.
Tushar Goel said…
Yup, i checked that video, it is awesome.

I understood your point that due to Family responsibilities and other stuffs,
you get little time to do other things.

Do share if you get some time. We will always waiting to learn something from you.

Popular posts from this blog

Double Checked Locking

I still get a lot of questions about whether double-checked locking works in Java, and I should probably post something to clear it up. And I'll plug Josh Bloch's new book, too. Double Checked Locking is this idiom: // Broken -- Do Not Use! class Foo {   private Helper helper = null;   public Helper getHelper() {     if (helper == null) {       synchronized(this) {         if (helper == null) {           helper = new Helper();         }       }     }   return helper; } The point of this code is to avoid synchronization when the object has already been constructed. This code doesn't work in Java. The basic principle is that compiler transformations (this includes the JIT, which is the optimizer that the JVM uses...

What Volatile Means in Java

Today, I'm going to talk about what volatile means in Java. I've sort-of covered this in other posts, such as my posting on the ++ operator , my post on double-checked locking and the like, but I've never really addressed it directly. First, you have to understand a little something about the Java memory model. I've struggled a bit over the years to explain it briefly and well. As of today, the best way I can think of to describe it is if you imagine it this way: Each thread in Java takes place in a separate memory space (this is clearly untrue, so bear with me on this one). You need to use special mechanisms to guarantee that communication happens between these threads, as you would on a message passing system. Memory writes that happen in one thread can "leak through" and be seen by another thread, but this is by no means guaranteed. Without explicit communication, you can't guarantee which writes get seen by other threads, or even the order in whic...

Atomicity, Visibility and Ordering

(Note: I've cribbed this from my doctoral dissertation. I tried to edit it heavily to ease up on the mangled academic syntax required by thesis committees, but I may have missed some / badly edited in places. Let me know if there is something confusingly written or just plain confusing, and I'll try to untangle it.) There are these three concepts, you see. And they are fundamental to correct concurrent programming. When a concurrent program is not correctly written, the errors tend to fall into one of the three categories: atomicity , visibility , or ordering . Atomicity deals with which actions and sets of actions have indivisible effects. This is the aspect of concurrency most familiar to programmers: it is usually thought of in terms of mutual exclusion. Visibility determines when the effects of one thread can be seen by another. Ordering determines when actions in one thread can be seen to occur out of order with respect to another. Let's talk about t...