andrewstellman

How funny! This is exactly the approach Jenny Greene and I took in Head First C# (O'Reilly), right down to the way we start with cards and suits, then ordering, building up to a complete card game.

Here's an article about my system, pbprdf: https://www.zdnet.com/article/nba-analytics-and-rdf-graphs-g...

And an example of its use: https://gist.github.com/andrewstellman/4872dbb9dc7593e56abdd...

Here's an example of what the RDF files generated by pbprdf look like:

Here's the ontology, which defines the vocabulary it uses: https://github.com/andrewstellman/pbprdf/blob/master/generat...

And this is what the data looks like:

  <pbprdf/games/2017-11-29_Warriors_at_Lakers/230> pbprdf:shotPoints "3"^^xsd:int ;
        pbprdf:shotAssistedBy <pbprdf/players/Klay_Thompson> ;
        pbprdf:shotType "26-foot three point jumper" ;
        pbprdf:shotMade "true"^^xsd:boolean ;
        a pbprdf:Shot ;
        pbprdf:shotBy <pbprdf/players/Stephen_Curry> ;
        a pbprdf:Play ;
        pbprdf:forTeam <pbprdf/teams/Warriors> ;
        pbprdf:inGame <pbprdf/games/2017-11-29_Warriors_at_Lakers> ;
        pbprdf:time "10:23" ;
        pbprdf:period "3"^^xsd:int ;
        a pbprdf:Event ;
        rdfs:label "Warriors: Stephen Curry makes 26-foot three point jumper (Klay Thompson assists)" ;
        pbprdf:secondsIntoGame "1537"^^xsd:int ;
        pbprdf:secondsLeftInPeriod "623"^^xsd:int .

I'm pretty sure the researchers were using a normal computer projector and not a slide projector. But in my imagination, they printed a bunch of slides, fed them into a carousel projector, and pointed them at an old Smuckers jelly jar full of resin.

Wait, what? The ability to see through walls and not require line of sight leads to fewer privacy concerns?

Seems to me the privacy concerns are significantly greater for radar than facial recognition. Radar can see places that cameras can't, and while it doesn't capture color information, it does capture detailed 3D data that camera-based systems need to interpolate.

Plus, you know, the whole working through walls thing. Seems like there are at least as many opportunities for abuse as with facial recognition technology.

That said, I think there are several advantages:

• It's more compact, with fewer lines and fewer characters, but at least as readable

• There's simple separation of concerns: it only has a single print statement – the whole range is transformed, then printed – which makes it easy to refactor later if I need to use those values for something other than printing

• It's obvious that all of the cases are handled

• In an amazing coincidence, it looks like code I write :) so I personally prefer it

If you're implying that there are times that if/elif/else syntax is more readable than pattern matching, then yes, absolutely! There are times when one is preferable, and times when the other is.

Pattern matching is especially nice when you need to include conditionals and types:

  vehicle match {
     case car: Car if (car.passengers > 2) => addToHovLane(car)
     case truck: Truck                     => reject("No trucks allowed")
     case _                                => totalTraffic += 1
  }

That said, sometimes (often!) the more compact code is, the harder it is to read. I think it's always worth taking a few extra characters to improver readability. So I only use pattern matching with types and discards when I think it makes the code more readable and more flexible (e.g. easier to refactor, improves separation of concerns).

BTW, thanks for pushing back on this. I'm working on the 4th edition of Head First C# (O'Reilly), and C# added syntax very similar to this (borrowed from F#). Writing this reply gave me the opportunity to start thinking through how I want to teach it.

  (1 to 100).map(i => (i % 3, i % 5) match {
    case (0, 0) => "FizzBuzz"
    case (0, _) => "Fizz"
    case (_, 0) => "Buzz"
    case _ => s"$i"
  }).foreach(println)

It was usually parked in the Field Robotics garage, but if you went out early on a weekend morning, you might catch it driving itself slowly around Schenley Park (which is right next to CMU campus) – without anyone at the wheel, which was really unreal and sci-fi-ish at the time.

I remember one story of a jogger who was surprised to suddenly run across it. The story goes that the he or she screamed and actually fainted. The truck was programmed to stop if it found itself in front of any obstacle, so when the jogger came to, there was the truck looming above.

I have no idea if the story is actually true, but I like it anyway.

https://twitter.com/AndrewStellman/status/107722796317793484...

> I used to think I was the one who had it all figured out. Adventurous life in the city! Traveling the world! Making memories! Now I feel incredibly hollow. And foolish. How can I make a future for myself that I can get excited about out of these wasted years?

I hope she can learn to stop thinking about those years as wasted. She saw and did things that most people never get to see or do because they're too busy working. Plenty of 35-year-olds are in debt, upside-down on their houses, in miserable marriages, and just a few years from getting divorced, buying a convertible, and dating someone inappropriately young for them. More than a few of them would envy her life.

Most people who have done a lot of options trading have seen this in practice: if you're trying to sell a really thinly traded option RIGHT NOW, most of the time the latest price is a higher than the price you'll get. That's because there was only one buyer at the time, and someone else got that person's bid. So now you'll have to go to the next-most-interested buyer, and you'll probably need to lower your asking price a bit because otherwise he or she would have been the most recent buyer.

All of this is masked in heavily traded markets. But it's a lot more apparent in housing. However, that's complicated by the fact that people REALLY HATE lowering their asking price, so instead of seeing prices drop, housing markets typically just see volume go down. And recent lower transaction prices are often dismissed by sellers ("That person was just desperate to sell, I'm going to wait for someone to pay what my house is worth").

Excellent work!

console.log("%c\t\t\t\t\t\t\t\t\t\t\t\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n Hi there! \n\nIt seems you like to poke around as much as we do.\n\nhttps://github.com/Microsoft/join-dev-design", "color: white; background-color: #080808; background-image: url(https://microsoft.github.io/join-dev-design/msft-square.svg)... background-size: 70%; background-position: 50% 25%; background-repeat: no-repeat; padding: 3em; text-align: center;font-size: 1.25em;");

The author links to the Hacker News thread where he learned about it: https://news.ycombinator.com/item?id=16542183

Happy to answer questions.

When Jenny Greene and I were working on our book, "Learning Agile: Understanding Scrum, XP, Lean, and Kanban," we were lucky enough to have David Anderson (the guy who adapted kanban for software development) review our chapter on Kanban, and he really helped us nail down this particular issue.

Other than that (and a few things he says about the PMP certification), what he says in the piece is spot on. Nice work -- I'd love to see it expanded into a book!

Specifically, tools for Apache Cordova: https://www.visualstudio.com/vs/features/cordova/

(disclaimer: I haven't used them, but I've heard very positive feedback)

See if you can start a virtuous cycle: try finding a way to make her life even a little bit easier without expecting anything in return. If you help solve her problems, she might help solve yours, and you can start functioning as a team.

I did my best to illustrate that here: https://twitter.com/AndrewStellman/status/896405621494382593

Tangled, nasty, poorly maintained code is not an easy problem to fix. The first step is getting everyone on the team -- and especially the boss -- to recognize the real problem, and accept that fixing it will save more time than it costs.

It's good that Facebook took steps to secure the platform against third parties crawling the graph and scraping millions of users' personal details, which is what Cambridge Analytica reportedly did, and which was not a violation of their policy at the time. Kudos.

So the consensus seems to be that what Cambridge Analytica did in the Brexit vote and the 2016 US Election was wrong. Now they won't be able to do the same thing via Facebook. But what's keeping Facebook themselves from doing the same thing that Cambridge Analytica did in future elections?

> The pointy-haired boss is a manager who doesn't program. So the surest way to avoid becoming him is to stay a programmer.

Staying a programmer is a good way to avoid becoming a pointy-haired boss, but I’ve seen many programmers become pointy-haired bosses even as they continue to write code. The most common way good people become bad bosses is to blame people for their mistakes, because they’re nervous about the commitments they make and don’t know how to leave themselves enough options. The closer you are to the code, the less likely you are to suffer from this prolem (but it still happens).

Jenny Greene and I wrote about this in Learning Agile: https://twitter.com/AndrewStellman/status/971810876830502912

A few years ago I put together a quick GUI in C# to make it easier to run SPARQL queries: https://github.com/andrewstellman/sparql-explorer

I haven't found an RDF editor or visual tool that I like. Some people like Topbraid Composer: https://www.topquadrant.com/tools/modeling-topbraid-composer... (commercial, closed source)

That's definitely an important benefit. RDF makes it really easy to introduce changes that not only don't break the existing schema, but can be entirely isolated or combined in queries.

Another thing that RDF makes easy is analysis that takes advantage of a graph -- using relationships with other players, shots, etc. What players have the highest percentage making 3-point shots in possessions immediately after a player on the other team missed a 3-point shot? Building queries you compare previous possessions, shots, quarters; players' relations to each other (e.g. performance players who were subbed in after previous teammates went scoreless for 3 possessions) -- these things are a lot easier to do in RDF than in SQL.

Obviously, there are many things that are easier to model in RDBMS and query in SQL than with RDF/SPARQL. Every tool has its uses.

That said, we've done some work to prevent runaway queries (e.g. strict query timeouts, downstream systems that handle that situation gracefully).

While a lot of the work I do is covered by NDA, one problem that I've applied it that I can talk about is analyzing basketball play-by-plays. I've spent some time talking to the analytics team at an NBA franchise, and it turns out doing interesting analytics on play-by-plays can be a surprisingly tough nut to crack. RDF was a great tool for tackling this. Here's the source (written in Scala), for anyone interested at having a look: https://github.com/andrewstellman/pbprdf

- Try to think about what your reader is thinking. It's not enough just to technically have stated something. Make sure you say it in a way that's easy to digest.

- Video games need playtesting. In the same vein, books need reader testing, especially when you're first starting out. Get other people to read your work.

- Work with what you have, but work hard at it. Writing is a skill. I'm a pretty good musician, a pretty good writer, and a pretty good programmer. I happen to have talent for all of those things. But I also did a LOT of playing music, a LOT of writing, and a LOT of coding -- starting when I was very young (well before my teenage years) -- to turn those talents into skills. Every good writer has done the same.

- If you want to be published, get a feel for how the actual publishing industry works; editors are people, they have jobs, make their jobs easier.

- Write, write, write. Then write some more.

And I think Jeremy Gibson Bond had some very useful advice about writing video games for either fortune or fame in his excellent book, "Introduction to Game Design, Prototyping, and Development":

> Designer-Centric Goals

>

> As a game designer and developer, there are some goals for your life that you hope the games you make might help you achieve.

>

> Fortune

> My friend John “Chow” Chowanec has been in the game industry for years. The first time I met him, he gave me some advice about making money in the game industry. He said “You can literally make hundreds of...dollars in the game industry.”

...

> Fame

> I’ll be honest: Very, very few people become famous for game design. Becoming a game designer because you want to be famous is a little like becoming a special effects artist in film because you want to be famous. Usually with games, even if millions of people see your work, very few will know who you are.

(Gibson Bond, Jeremy. Introduction to Game Design, Prototyping, and Development: From Concept to Playable Game with Unity and C# (p. 107). Pearson Education. Kindle Edition.)

If you want to get rich and/or famous, don't go into writing. Make sure you know your own personal goals. If you want to shoot for the stars, that's great -- just make sure you know what you want.