Hacker Newsnew | past | comments | ask | show | jobs | submit | dustinfarris's commentslogin

how is this different from using PGP with Gmail?


As far as I know, Gmail doesn’t allow saving PGP keys or using them to write new emails, whereas mailbox.org integrates the entire PGP service and to send an email, even from iOS where PGP apps are "ugly," you just need to do it from the web interface.

Anyway I wrote the details in the post.

Edit: I have to mention that I generated my PGP keys locally and then imported to Mailbox.Org


Note that when you let a provider do PGP for you, you're not safe from that provider. It's one of the big problems with PGP: you can have usability or security but not both.


Do gmail prevents you from using a regular MTA these days?


You're doing it without 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.


I've been concerned about buying into the Touch Bar hardware when it seems like it is not coming to any other Macs.

If Apple was going to try and open a new front on the "hearts and minds of Touch Bar skeptics" war then the Mac Pro reveal at WWDC a few weeks ago would have been the time to do it, that they didn't makes me think it's not long for this world. Not because the Mac Pro sales would have been hampered by it, if a workstation class modular PC running macOS was what you have been waiting for then wrapping the cost of a Touch Bar keyboard wouldn't be a make or break price modifier (and you could always swap out keyboards later if you hate it).

If the MBP is a quasi-halo product (expensive but incredibly ubiquitous) and the Touch bar isn't coming to the Mac Pro which is a true halo product I don't think you'll see it ever get pushed to any other product category either.


If memory serves, the logic to drive the Touch Bar is something that came from the Watch, which also included the Secure Enclave and other features that were more mobile than desktop. If that was true, then you can't trust the USB cable alone (or Bluetooth) to maintain the trust that circuit needs, and a keyboard with a Touch Bar would require a new circuit or at least design change to only do the display part, not the rest. It makes sense they won't put it in standalone keyboards just yet.


I tended to agree with this, but really with the desktop setup you have to move your eyes and head much farther to see the keyboard because the monitor is not fixed to it. This may be why they don't produce keyboards with the touchbar - the experience would be even less appealing.


I had forgotten the Touchbar was possibly to get life on the magic keyboard. I agree if this was to happen, it should have been bundled with the Mac Pro.

I also think the Touchbar apps being migrated to Sidecar may be a clue that a deprecation path exists should the dedicated hardware go away. “They live in sidecar now.”


You could also just set your dock to autohide. That's what I do on my MBA 2015 and it's great, especially considering how small 1440x900 already is.


If you’re hiding the dock, reducing the delay is very useful:

    defaults write com.apple.Dock autohide-delay -float 0 && killall Dock


If you also have an iPad, the Touch Bar will make an appearance on that when using it as a second screen in Catalina's upcoming Sidecar feature: https://www.macrumors.com/2019/06/05/apple-sidecar-app-has-t...

Not as useful as when it's right next to the keyboard, but that's probably the closest other Macs are going to get.

I could sort of imagine Apple making a desktop keyboard with one, but it seems better suited to a wired keyboard than bluetooth. You'd have to recharge the battery way more often.


I'm hoping sooner or later someone figures out how to bind/call arbitrary elisp functions from the touchbar. That for me would be the real killer app.


Just downloaded it! I have to agree that this is a much better use than the default one. The original one was hardly usable in many applications besides music players. This gives me the ability to switch apps quicker than before, especially with many full screen apps open. Thanks man.


I've been using TouchSwitcher for a good while now: https://hazeover.com/touchswitcher.html


> devote time to learning Touch Bar

How complicated do you think it is that you need to spend time learning it?


Not complicated at all, it just requires an open mindset.

Some tips:

Customise it to your liking in the keyboard pref pane.

You can press-and-drag on volume and brightness buttons of the collapsed control strip. No need to tap then slide.

You can create services (now Quick Action) in Automator and they show up with the Show Quick Actions setting set. Since services can be contextual (input+app) you can get creative and do some whacky stuff in there. I have contextless Safari and Terminal there to pop up new windows whatever the focused app is.


What I CAN NOT do, however, is move the 'ESC' key (or any, really) all the way to the left. There's always a 'Touch ID'-size spacer on the left of the Touch Bar.


That spacer still activates the 'ESC' key


That's correct. I am currently considering upgrading from my 13" 2013 Macbook Air to a 15" 2019 Macbook Pro (I want it for the IPS/bigger display) and I noticed this while I was testing it at Bestbuy.

Personally, if I make the purchase, I will probably just remap the Caps Lock key to ESC - assuming I can remove ESC from the Touch Bar.

The one thing I didn't care for is that the Touch Bar display can time out. I would personally prefer that it stay on - or at least have the option of it staying on.


Did a quick test, seems like it times out after 2min of system idle time, unrelated to display timeout (caffeinate -d doesn't prevent it) or actual idle system state (caffeinated -I doesn't either), and even on AC power (to prevent OLED burn in?)

The timeout implementation could definitely be improved. In 6 months I've hat that computer I've never had it be a problem or even found it annoying in any way though.


it sort of does. pressing in the 'middle' of the space, yeah, but not tapping the edge, like I used to do with the physical key.


Indeed the ESC button is much wider than it appears to be.


After 4 weeks with a touchbar macbook I’m still trying to unlearn “finger rests near escape key”, mostly because I only use the built in keyboard occasionally and that’s where that finger belongs.


It's also about unlearning one's previous workflows.


We have ubar for that https://brawersoftware.com/products/ubar


I use Logic Pro heaps - and the touch par is actually useful there. The issue for me is remembering that it's there. I am so used to the keyboard commands.


The thing that should concern you more about upgrading is the fact that they now solder the hard drive into the motherboard and the keys break and once broken also requires replacing the whole machine. Oh and they have no travel either. Maintainability? Who cares about that!


Now they just need to add the missing row of keys, and everything will be fine.


Sidecar adds a Touch Bar on the iPad to all Macs that support Sidecar.


Agree, the dock is what the touch bar should default to. I do wonder, if any, what the battery impact is with Pock?


The lack of a Touch Bar on desktop Macs is ridiculous, but I generally like it. Especially when I realized that you don't for example, touch volume, wait, and slide, but just start sliding from the little button in the quick menu.


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.


But you can't. The moment you need to do a layout, you're back into html + css and it's inabilty to cater to anything beyond single-page documents (not apps) ;)


Actually server side rendering is comming, it's working in a hacky way, but it's promising.


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.


I'm suggesting it doesn't 'work fine', because syntax matters.

Lisp-style 'S-expression' syntax for describing documents never took off. We have to take something from that - it seems the vast majority of developers don't enjoy that syntax, irrelevant of how 'simple' its just-functions nature makes it.

JSX also 'targets DOM nodes', but I don't see what that has to do with anything.

The closer correspondence between how JSX looks, what you see in your browser DevTools, and how it seems that most developers prefer to mentally model documents ... is where the win comes from IMO.

The reality is the vast majority of React code I see uses JSX, even though it's optional. It's been hugely successful in React world and I don't think that should be ignored by Elm.


I'd say the problem isn't "this is not JSX", but that the syntax just looks awful:

     div []
        [ div [] [ button [ onClick Increment ] [ text "+" ] ]
        , div [] [ text <| toString model.counter ]
        , div [] [ button [ onClick Decrement ] [ text "-" ] ]
        ]
JSX isn't the only syntax that took off, there are for example indentation based syntaxes for HTML, theoretically:

    div
      div
        button onClick: Increment
          text "+"
      div
        text <| toString model.counter
      div
        button onClick: Decrement
          text "-"
already much nicer (and if it was all wrapped in parens it wouldn't make much of a difference).

Given that Elm is "just" for making HTML apps, this does seem like something the language should focus on.


Your syntax only looks good in hello-world examples and will stumble upon the same sort of ambiguities that things like coffeescript grappled with.

It turns out that it's less work to always have delimiters than it will be to have to add them anyways to disambiguate.


It's an interesting balancing act. I think when most devs look at JSX for the first time they instantly recoil at the rebellion against years and years of "separation of concerns", yet as you say it's a syntax that devs have embraced regardless.

I love Elm and think it or something very close to it should become way more mainstream, but I do find its bracket-heavy DOM syntax off-putting in comparison.

EDIT: That said, I do agree with the leading commas in laying out models as opposed to the trailing. Scanning the models of an Elm file is far faster than, say, a JS file, subjectively at least.


HTML and XML for describing documents also never took off; they are largely generated from something else rather than hand-edited.

Thus, no structural, recursive syntax for document editing has "taken off".

Word processing is still done in Microsoft Word by most of the planet. HTML e-mails are written in some WYSIWYG client program. Web forums use variations on markdown (with raw HTML only as an escape hatch).

People do work with *ML by hand, but largely reluctantly.

If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.


HTML and XML took off for web. That's what the vast majority of devs write and that's how all devtools display the DOM.

> If you do have to roll up your sleeves and work with the serialized syntax, you're far better off it its is S-expresions.

Convince the masses, because they don't seem to agree.


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...


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!


Thanks for sharing!

What are the biggest pros/cons you've encountered so far? What do you miss from Django? What do you wish Django could copy from Phoenix?


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 found Ecto to be one of the best Postgres libraries out there.

What do you miss from Django's Postgres libraries in Phoenix/Ecto?


Another Django -> Phoenix dev here. Currently I miss Django's model field types (UrlField, EmailField, etc) and will probably write them if no one else does soon. I sometimes miss South style migrations when I'm prototyping but doubt there's a good reason to implement them in Phoenix. For building JSON APIs JA Serializer is a quite capable alternative to DRF-JA.

For the Django Admin there's ex_admin which I haven't used yet but it appears to take a bit more work than the Django Admin does.

I haven't felt like virtualenv + pip was too bad for deps and deployment but exrm is already comparable/easier with an even better `mix release` planned for this summer/fall. No uwsgi or gunicorn to configure and even nginx can be skipped.

For the last part of your question: the biggest thing missing from Django was a good way to do websockets. Django has channels now but I doubt they'll work like Phoenix/OTP/Erlang (especially in the concurrency and fault tolerance categories).


Is it common to skip nginx or insert-your-reverse-proxy-of-choice-here?

I'm working on a Phoenix app, getting close to being ready for a beta deployment, and I was just looking for best practices as far as putting it in production.


From what I've read (I'm not an expert either) nginx is completely optional. Cowboy (used by Phoenix) supports https termination and I understand that it's the router for Heroku so it sees plenty of traffic.


+1 to rattray's questions. Some more questions: do you think Django is showing its age? Should new web projects be started in new frameworks like Phoenix, or is Django still good to go?


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.


It's been awhile since I've used Django, but I work with those who use it frequently. Django certainly shouldn't be put out to pasture- but you'd be surprised just how robust and production-ready Phoenix is.

Of course, no one can tell you whether it's good for your particular business case- but Erlang is battle-tested, and Elixir/Phoenix have made it both easy to reason about and perfect for being productive. If one had the option of choosing a framework right now, I don't know of many reasons to not use Phoenix.


> I don't know of many reasons to not use Phoenix.

Personally my biggest reservation would be the difficulty of debugging production issues that span two languages - Elixir and Erlang – when I have no familiarity with the underlying language (and when that language is not widely used, and therefore likely to be sparse on StackOverflow).

That's not to say I wouldn't use Phoenix; it's just that that's the biggest drawback I can think of (aside from general ecosystem maturity, which it sounds like is on an impressive clip).

EDIT: Oh, and Elixir doesn't have support for static type analysis (though it does have typespecs[0], and there is Erlang's dialyzer[2]...). Python has mypy[1], and JavaScript has TypeScript/Flow.

[0] http://elixir-lang.org/getting-started/typespecs-and-behavio...

[1] http://mypy-lang.org/

[2] http://erlang.org/doc/man/dialyzer.html


In the year or so I've been working with Elixir, I've not had to learn a lick of Erlang besides a couple of function calls I can get at directly from Elixir.

Nor have I heard of anyone else having that issue. It's one of the reasons I enjoy it so much- I get all the performance with none of the complexity.


Same here. There's only one minor thing that bugs me a bit - Phoenix seems laid out more similar to RoR than to Django, so took me a bit of getting used to. This is not a criticism by any means. Overall, I'm really thrilled with Phoenix (and Elixir).


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!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: