dustinfarris

how is this different from using PGP with Gmail?

This is what Touch Bar should have been from the beginning IMO. I've been on the fence to upgrade my 2012 MBP. I've been concerned about buying into the Touch Bar hardware when it seems like it is not coming to any other Macs.

Why should I devote time to learning Touch Bar and trying to find ways to integrate it with my workflow when keyboard shortcuts are more than enough—and probably better? What happens when I sit down at my iMac where I spend >50% of my time?

Pock. has the answer. Turn the Touch Bar into the Mac Dock. Full screen everything and still have quick visuals on app notifications. Don't have to command-tabtabtabtab to get to a different open app—just tap it on the dock in Touch Bar. It's the perfect solution to an actual problem—give me more space on a small screen without sacrificing any of the experience.

Agreed, I learned Elm a year ago and haven’t looked back. Love being able to dismiss all other frontend web talk without a second thought.

If you feel like giving Ember another whirl in the future, ember-redux is production-ready and has a comparable API to react-redux. (e.g. `connect`)

https://github.com/ember-redux/ember-redux

Why introduce additional syntax when the native language works fine?

Elm is a functional language, and you build the desired DOM structure with functions. Why should it be any other way?

JSx looks sort of like HTML, but HTML isn't even the target here, just DOM nodes.

Incredible turnaround! I remember seeing Dan Abramov's tweet [1] a while back saying React could learn from Ember's CLI. Two weeks later, here it is! Impressive!

[1]: https://twitter.com/dan_abramov/status/752863664290553856

I just wrote a guide to use eDeliver to deploy Phoenix projects: https://www.gitbook.com/book/dustinfarris/phoenix-continuous...

Channels will eventually be part of Django core; it just didn't make the 1.10 release.

https://groups.google.com/forum/#!topic/django-developers/QR...

Answered rattray's question.

I think Django is showing its age, but not in a bad way, in a mature way. I truly admire the way Django and its core team have matured. They have been role-models for me for years and still are.

Django's momentum is only getting greater. Mozilla has been dumping money into it recently, and important projects like Django REST Framework are getting funded as well. Django is level-headed and forward-facing. I can't emphasize the importance of those two characteristics enough. Look no further than projects like Andrew Godwin's django-channels for evidence. I think starting a new project in Django absolutely sets you up for success.

That being said, Phoenix is terrific so far. It's fast, fun, and the Erlang/OTP concurrency story is really exciting! I'm lucky to be at a place where I can take a few months to really explore it; and I'm loving it! I will choose Phoenix for my future projects, but not because Django is losing any steam.

I'm still learning, but I've already noticed some incredible response times. Phoenix is very fast. I wish I had actual numbers to give you that compare to Django but I'm just not that far along yet.

Elixir as a language is very nice. This is my first taste of "functional" programming and I really like it. Shifting my mindset from object-oriented has been difficult, but I find the code I write much more straight-forward so far for the types of apps I will be building.

What do I miss? Maturity. Django dotted its Is and crossed its Ts a long time ago. I wouldn't say Phoenix is buggy at all—I think it is production ready—but the recent work Django has been doing with things like Postgres libraries are several steps ahead of where Phoenix is at today. Also, Django documentation is bar-none.

There is nothing about Phoenix that jumps out at me and says "Django would be so much better if it had this!" Maybe Presence will be one of those things, but I have not had a chance to play with it yet. I am excited about how Elixir (on top of Erlang OTP) scales horizontally with virtually no effort, which is something that Python cannot replicate as easily without a lot of thought and some sort of bolted on message db—and in the end, slower. The robust concurrency story (and what that could mean long-term) is exciting to me.

I'm 10-years Python/Django and making the leap to Phoenix. I can't begin to describe how thrilled I am with the intelligence and warmth of this community—something I always treasured at Django and was afraid of losing.

Phoenix 1.2 looks ready for prime-time! I just finished setting up a continuous integration/deployment pipeline with edeliver and CircleCI and couldn't be happier with how everything is fitting together.

Very excited for the bright future of Phoenix!

Evernote is just out of touch:

> So sorry about this - we've been trying to avoid calling this "markdown support" because, to your point, it clearly is not... sorry for (our) miscommunication!

I've been using Python 3 for all new projects for over a year. It was painful in the beginning, but my recent experience has been very rewarding. The few libraries that I use that have not been ported have, in almost all circumstances, been replaced by better libraries—I presume that this explains the lack of motivation to port the old ones.

That said, there are respected programmers who have good criticisms of Python 3[1] that are more level-headed than this sensationalized article; however, that has not stopped the community at large from moving to Python 3 where possible.

Also, as myself and others continue picking up LXC technology (Docker) the issue of host/ops dependencies interfering with project dependencies will gradually vanish—which is the only legitimate point made by the posted article. The title should have been: "My first day with Python 3"

[1]: http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

Letters like this go back and forth between companies all the time. It doesn't even sound threatening to me. Just a standard legal complaint. I'm sure there were a handful of phone calls made first. Sony and Twitter couldn't figure it out over the phone, so Sony sends the official letter saying, "here's why we're upset, this is what we want you to do about it, if you don't we will climb the legal ladder some more until it's all straightened out."

There's a lot more to a lawsuit than just winning or losing. By the time this is over, the public will (should) know _exactly_ what is happening, and _exactly_ what the legal basis for it is (should the EFF lose). With that knowledge, we can advocate for specific legislative change.

Assuming that the NSA would continue on regardless of winning or losing is to have zero confidence in our legal system. While there may be some ground for skepticism, using all available tools is absolutely appropriate.

EFF joins the ranks of ACLU in my book. Donated.

Thanks for the answer, and thanks for the links. I gave DRF+Haystack serious consideration already—in fact, I built a prototype using these packages. The reason I do not want to move forward with them is that they make the assumption that you will be using Django's ORM and some sort of SQL store for persistence with Elasticsearch bolted on top. My intention is to use Elasticsearch exclusively. I also want to use the API with Ember.js, which is difficult given the differing JSON format opinions between DRF and Ember.js (see ember-django-adapter[1]).

I've also noticed that Haystack's owner has been inactive recently which concerns me. This in itself gave me a reason to check out Elasticsearch's own Python bindings[2] which aren't that scary after all.

I am looking at Gorilla web toolkit (thanks for the link!).

[1]: https://github.com/dustinfarris/ember-django-adapter

[2]: https://github.com/elasticsearch/elasticsearch-py

I actually went through the Golang quickstart before writing my original post. It is very tempting, but I'm concerned it might be a long journey for what should be a simple app. In your experience, how productive is Go at kicking out basic CRUD APIs?

I'm familiar with DRF, and yes, it is terrific. However, because I want to interface directly with Elasticsearch, I am inclined to drop Django altogether.

Sinatra looks very straight-forward. Checking out the repo on GitHub now, and it looks great! I will probably do some sort of token-based auth. The app will eventually integrate with Ember.js.

Can you elaborate?