Artwork

コンテンツは Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャスト コンテンツは、Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones またはそのポッドキャスト プラットフォーム パートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal
Player FM -ポッドキャストアプリ
Player FMアプリでオフラインにしPlayer FMう!

Ep 110: Contextify!

23:22
 
シェア
 

Manage episode 399978728 series 2463849
コンテンツは Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャスト コンテンツは、Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones またはそのポッドキャスト プラットフォーム パートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "gathering debugging context". Our downloads fail at random, but our dead program won't give us any answers.

Our discussion includes:

  • Sportify! Now, with even more exceptions!
  • How do you know the state of the application after it has already died?
  • Where do you catch the exception?
  • What do you log and where?
  • How do you get the context to where you need it?
  • What place has all the important context?
  • Where does the pure logic belong?
  • How can you keep I/O functions ruthlessly simple?
  • The beauty of fully described operations.

Selected quotes

  • We just need to fill out our support ticket and say, "Hey! Fix your service!" It couldn't possibly be our code!

  • So there is an error happening, but what happened just before that error?

  • It is dead. There's no way to ask it any questions. It will not give us any answers.

  • The only way to know what the program was doing, is to know what the program was doing. If you're trying to figure out what the program was doing by reverse engineeringing it, you're going to get it wrong.

  • I love hiding side effects with macros! That's one of my favorite things to do in Clojure! It makes me feel like I'm using Scala again!

  • We don't want the I/O function to do any thinking of any kind. It's a grunt. We fully specify the bits it needs to know. It's 100% a boring outcome of what we passed into it.

  • Those I/O functions end up being ruthlessly simple. They're often just one line!

  • We remove the thinking, so we remove the information. It's not because we don't like pure functions. We put them in a place where we can have all the information in one place.

  • We're getting to the point where our let block is getting really long really—maybe too long. We're really letting ourself go!

Links

  continue reading

118 つのエピソード

Artwork

Ep 110: Contextify!

Functional Design in Clojure

71 subscribers

published

iconシェア
 
Manage episode 399978728 series 2463849
コンテンツは Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones によって提供されます。エピソード、グラフィック、ポッドキャストの説明を含むすべてのポッドキャスト コンテンツは、Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones またはそのポッドキャスト プラットフォーム パートナーによって直接アップロードされ、提供されます。誰かがあなたの著作物をあなたの許可なく使用していると思われる場合は、ここで概説されているプロセスに従うことができますhttps://ja.player.fm/legal

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "gathering debugging context". Our downloads fail at random, but our dead program won't give us any answers.

Our discussion includes:

  • Sportify! Now, with even more exceptions!
  • How do you know the state of the application after it has already died?
  • Where do you catch the exception?
  • What do you log and where?
  • How do you get the context to where you need it?
  • What place has all the important context?
  • Where does the pure logic belong?
  • How can you keep I/O functions ruthlessly simple?
  • The beauty of fully described operations.

Selected quotes

  • We just need to fill out our support ticket and say, "Hey! Fix your service!" It couldn't possibly be our code!

  • So there is an error happening, but what happened just before that error?

  • It is dead. There's no way to ask it any questions. It will not give us any answers.

  • The only way to know what the program was doing, is to know what the program was doing. If you're trying to figure out what the program was doing by reverse engineeringing it, you're going to get it wrong.

  • I love hiding side effects with macros! That's one of my favorite things to do in Clojure! It makes me feel like I'm using Scala again!

  • We don't want the I/O function to do any thinking of any kind. It's a grunt. We fully specify the bits it needs to know. It's 100% a boring outcome of what we passed into it.

  • Those I/O functions end up being ruthlessly simple. They're often just one line!

  • We remove the thinking, so we remove the information. It's not because we don't like pure functions. We put them in a place where we can have all the information in one place.

  • We're getting to the point where our let block is getting really long really—maybe too long. We're really letting ourself go!

Links

  continue reading

118 つのエピソード

すべてのエピソード

×
 
Loading …

プレーヤーFMへようこそ!

Player FMは今からすぐに楽しめるために高品質のポッドキャストをウェブでスキャンしています。 これは最高のポッドキャストアプリで、Android、iPhone、そしてWebで動作します。 全ての端末で購読を同期するためにサインアップしてください。

 

クイックリファレンスガイド

探検しながらこの番組を聞いてください
再生