3 ms·

Learn Phoenix with Step by Step Screencasts

64 points by tortilla 10y ago

rubyn00bie 10y ago
Okay so admittedly I'm ignorant to the true content of the screencasts-- but I'd like to say something on things like this: With elixir and more specifically, BEAM and Erlang, the issue isn't "how to do X" it's "how to do X with BEAM." A lot of folks are coming to the ecosystem which is wonderful-- but by not learning the alternative paradigm (which is easy because the Ruby-esque appearance) they're missing the true beauty of BEAM/Erlang. As I've shipped to production Elixir apps-- I've felt this personally. Ive also learned a lot from doing so... The most valuable lessons haven't been "how to use Phoenix" or "how to do X in elixir." Rather, I've learned, lot of the elixir community is reinventing the wheel instead of using the ones (Erlang/BEAM) we already have. There's a reason you can't find a "tutorial to do X" because the problem is probably largely solved through idioms provided by the language and platform being designed to work together. Erlang has mature web frameworks, database adapters, etc. and it would/does benefit one to learn them. To learn how they function and WHY they function that way. Not to sell the authors of this short, but an insane amount of Phoenix is very easy to learn once you learn these principals. The reason being Erlang is idiomatic (generally) in how problems are solved. Phoenix becomes simply "implementation details." Not something truly "new." -- Note: It's late hopefully this isn't nonsensical.
- brightball 10y ago
  On the one hand I certainly see why you could interpret it that way. On the other hand, Elixir seems to emphasize the easy use of existing Erlang libraries on a regular basis for everything from crypto to leveraging BEAM for hot deployment. Regarding mature web frameworks - there are a lot of those for every language. What's attracting people to Phoenix isn't it's maturity, it's the lessons learned from other very mature frameworks that can't easily be fixed without a full rebuild. There's too much in that area to get into without a series of blog posts. The other area where you're seeing some reinventing is usability. Drawing in people from the Ruby community around Elixir has a huge amount of value because there's no programming community that I've ever been around that puts developer workflow and efficiency at such a high premium. There may be perfectly good libraries to use as the basis for functionality but the odds are good that if those libraries have too high of a barrier to entry, someone will try to improve that. That's most of what I've seen at least. Elixir folks that I've observed so far have done very little other than singing the praises of what's already in Erlang/BEAM. I'm seeing emphasis placed on Observer, HiPE and Dialyzer. EXRM is abstracting a lot of what needs to happen to automate BEAM hot code deploys and now there's another library Edeliver that wraps EXRM to further streamline the process for developers. Just my observation of the community so far, but it definitely seems to me like most of the reinvention is coming from the developer streamlining standpoint which is only going to make things more accessible to more people.
  - rubyn00bie 10y ago
    Err I guess you sort of brought some points that I've learned through pain: * ) Hot code reloading is only done in scenarios where it must be. It's not something that's common or recommended in Erlang/BEAM. Most everyone actually just does rolling restarts. * ) EXRM is one the most frustrating pieces of software I've ever used. I don't mean offense to the folks working on it, but it's caused me days of lost time. I'm actually moving to just using RelX-- its vastly simpler without the "magic." EDeliver is mostly just one helluva shell script. You could accomplish the same with say, Capistrano, or by hand pretty easily. I know, cuz I done it. * ) Re: web frameworks, as I've found getting more exposure in the Erlang world-- most folks are already so productive in Erlang because of it/BEAM it seems silly to use monolithic frameworks. This was perhaps the most shocking revelation I had. I think as we Rubyists enter the community and "want to improve it," without learning why it's done this way-- we're just gonna push a community of bad solutions. Or solutions that probably aren't really needed after the first few weeks with the platform. Looks at exrm. ... Hopefully this came off as a discussion (on my part) and not hating on folks or the hardwork theyve shared with the community. My apologies if that's not how it came off... I've just been feeling more frustrated with Elixir (still love it) and they've have been solved by not using an "Elixir" solution but instead using the "old school Erlang" solution.
    - brightball 10y ago
      That's the thing about Phoenix though, it's not a monolithic framework because of Elixir. There's actually some great talks about that at ElixirConf too such as "Phoenix is not your application" emphasizing that Phoenix is nothing more than an interface to get to the actual parts of your application. Admittedly, I'm only just getting into exrm so it's a bit hard for me to say just exactly how complicated it will end up being.
- guejwhwc 10y ago
  Would you mind linking to some resources you'd recommend to start learning if you were starting today? I'm just starting to learn elixir and Phoenix, but I'd be interested in how you'd approach it today.
  - rubyn00bie 10y ago
    My biggest tip, is get down with OTP... It's the "magic." http://learnyousomeerlang.com/what-is-otp http://learnyousomeerlang.com/what-is-otp http://erlang.org/doc/design_principles/des_princ.html http://erlang.org/doc/design_principles/des_princ.html Don't do "defensive coding," it violates the core principal of BEAM: let it fail, it will recover. http://c2.com/cgi/wiki?LetItCrash http://c2.com/cgi/wiki?LetItCrash How releases work: http://erlang.org/doc/design_principles/release_handling.html http://erlang.org/doc/design_principles/release_handling.htm...
  - sotojuan 10y ago
    Aside from the links already posted, Elixir in Action's second part is all about OTP and BEAM.
- danielberkompas 10y ago
  Author here. I do make an effort to bring out Erlang and BEAM wherever possible in my screencasts. One thing to keep in mind is that many developers coming to Elixir/Phoenix come from Rails, where these idioms are lacking. They need to change their mindset. They're looking for "How do I do X" tutorials, so I try to create those and use them as opportunities to introduce Erlang/BEAM.
sergiotapia 10y ago
The first episode is free but it's just intro yada yada yada. Maybe make the second episode free to see what the content is actually like.
- danielberkompas 10y ago
  Author here. Content will be similar to my other screencast at www.learnelixir.tv, but with more actual app building. See www.learnphoenix.tv/upcoming for details on planned episodes.
programminggeek 10y ago
It looks good, but I think pitching the benefit of Phoenix instead of pitching the benefit of the screencasts is a mistake. I'd imagine the people willing to buy are already convinced that Elixr and Phoenix are awesome. Also, it seems to make sense to do a subscription instead of a flat amount, OR do both.
- danielberkompas 10y ago
  Author here. A flat amount is more achievable for more people, and it also allows the screencast series to eventually be "finished". I don't want to burn out like Railscasts did. > I think pitching the benefit of Phoenix instead of pitching the benefit of the screencasts is a mistake. Thanks for the feedback here. I'll keep that in mind as I continue to work on it.
xiaoma 10y ago
This looks kind of interesting. The basic modules are a smaller version what you'd expect to get from a major publisher's "Programming ________" book, but the apps in the upcoming section look like a unique value. Anyone know when the multiplayer game video will be out?

64 points by tortilla 10y ago

Okay so admittedly I'm ignorant to the true content of the screencasts-- but I'd like to say something on things like this: With elixir and more specifically, BEAM and Erlang, the issue isn't "how to do X" it's "how to do X with BEAM." A lot of folks are coming to the ecosystem which is wonderful-- but by not learning the alternative paradigm (which is easy because the Ruby-esque appearance) they're missing the true beauty of BEAM/Erlang. As I've shipped to production Elixir apps-- I've felt this personally. Ive also learned a lot from doing so... The most valuable lessons haven't been "how to use Phoenix" or "how to do X in elixir." Rather, I've learned, lot of the elixir community is reinventing the wheel instead of using the ones (Erlang/BEAM) we already have. There's a reason you can't find a "tutorial to do X" because the problem is probably largely solved through idioms provided by the language and platform being designed to work together. Erlang has mature web frameworks, database adapters, etc. and it would/does benefit one to learn them. To learn how they function and WHY they function that way. Not to sell the authors of this short, but an insane amount of Phoenix is very easy to learn once you learn these principals. The reason being Erlang is idiomatic (generally) in how problems are solved. Phoenix becomes simply "implementation details." Not something truly "new." -- Note: It's late hopefully this isn't nonsensical.

brightball 10y ago
On the one hand I certainly see why you could interpret it that way. On the other hand, Elixir seems to emphasize the easy use of existing Erlang libraries on a regular basis for everything from crypto to leveraging BEAM for hot deployment. Regarding mature web frameworks - there are a lot of those for every language. What's attracting people to Phoenix isn't it's maturity, it's the lessons learned from other very mature frameworks that can't easily be fixed without a full rebuild. There's too much in that area to get into without a series of blog posts. The other area where you're seeing some reinventing is usability. Drawing in people from the Ruby community around Elixir has a huge amount of value because there's no programming community that I've ever been around that puts developer workflow and efficiency at such a high premium. There may be perfectly good libraries to use as the basis for functionality but the odds are good that if those libraries have too high of a barrier to entry, someone will try to improve that. That's most of what I've seen at least. Elixir folks that I've observed so far have done very little other than singing the praises of what's already in Erlang/BEAM. I'm seeing emphasis placed on Observer, HiPE and Dialyzer. EXRM is abstracting a lot of what needs to happen to automate BEAM hot code deploys and now there's another library Edeliver that wraps EXRM to further streamline the process for developers. Just my observation of the community so far, but it definitely seems to me like most of the reinvention is coming from the developer streamlining standpoint which is only going to make things more accessible to more people.
- rubyn00bie 10y ago
  Err I guess you sort of brought some points that I've learned through pain: * ) Hot code reloading is only done in scenarios where it must be. It's not something that's common or recommended in Erlang/BEAM. Most everyone actually just does rolling restarts. * ) EXRM is one the most frustrating pieces of software I've ever used. I don't mean offense to the folks working on it, but it's caused me days of lost time. I'm actually moving to just using RelX-- its vastly simpler without the "magic." EDeliver is mostly just one helluva shell script. You could accomplish the same with say, Capistrano, or by hand pretty easily. I know, cuz I done it. * ) Re: web frameworks, as I've found getting more exposure in the Erlang world-- most folks are already so productive in Erlang because of it/BEAM it seems silly to use monolithic frameworks. This was perhaps the most shocking revelation I had. I think as we Rubyists enter the community and "want to improve it," without learning why it's done this way-- we're just gonna push a community of bad solutions. Or solutions that probably aren't really needed after the first few weeks with the platform. Looks at exrm. ... Hopefully this came off as a discussion (on my part) and not hating on folks or the hardwork theyve shared with the community. My apologies if that's not how it came off... I've just been feeling more frustrated with Elixir (still love it) and they've have been solved by not using an "Elixir" solution but instead using the "old school Erlang" solution.
  - brightball 10y ago
    That's the thing about Phoenix though, it's not a monolithic framework because of Elixir. There's actually some great talks about that at ElixirConf too such as "Phoenix is not your application" emphasizing that Phoenix is nothing more than an interface to get to the actual parts of your application. Admittedly, I'm only just getting into exrm so it's a bit hard for me to say just exactly how complicated it will end up being.
guejwhwc 10y ago
Would you mind linking to some resources you'd recommend to start learning if you were starting today? I'm just starting to learn elixir and Phoenix, but I'd be interested in how you'd approach it today.
- rubyn00bie 10y ago
  My biggest tip, is get down with OTP... It's the "magic." http://learnyousomeerlang.com/what-is-otp http://learnyousomeerlang.com/what-is-otp http://erlang.org/doc/design_principles/des_princ.html http://erlang.org/doc/design_principles/des_princ.html Don't do "defensive coding," it violates the core principal of BEAM: let it fail, it will recover. http://c2.com/cgi/wiki?LetItCrash http://c2.com/cgi/wiki?LetItCrash How releases work: http://erlang.org/doc/design_principles/release_handling.html http://erlang.org/doc/design_principles/release_handling.htm...
- sotojuan 10y ago
  Aside from the links already posted, Elixir in Action's second part is all about OTP and BEAM.
danielberkompas 10y ago
Author here. I do make an effort to bring out Erlang and BEAM wherever possible in my screencasts. One thing to keep in mind is that many developers coming to Elixir/Phoenix come from Rails, where these idioms are lacking. They need to change their mindset. They're looking for "How do I do X" tutorials, so I try to create those and use them as opportunities to introduce Erlang/BEAM.

sergiotapia 10y ago

The first episode is free but it's just intro yada yada yada. Maybe make the second episode free to see what the content is actually like.

danielberkompas 10y ago
Author here. Content will be similar to my other screencast at www.learnelixir.tv, but with more actual app building. See www.learnphoenix.tv/upcoming for details on planned episodes.

programminggeek 10y ago

It looks good, but I think pitching the benefit of Phoenix instead of pitching the benefit of the screencasts is a mistake. I'd imagine the people willing to buy are already convinced that Elixr and Phoenix are awesome. Also, it seems to make sense to do a subscription instead of a flat amount, OR do both.

danielberkompas 10y ago
Author here. A flat amount is more achievable for more people, and it also allows the screencast series to eventually be "finished". I don't want to burn out like Railscasts did. > I think pitching the benefit of Phoenix instead of pitching the benefit of the screencasts is a mistake. Thanks for the feedback here. I'll keep that in mind as I continue to work on it.

xiaoma 10y ago

This looks kind of interesting. The basic modules are a smaller version what you'd expect to get from a major publisher's "Programming ________" book, but the apps in the upcoming section look like a unique value. Anyone know when the multiplayer game video will be out?