cballard

Actually, you can do that, it's "Muting" the channel. Click the gear icon for that channel and go to notification preferences.

I'm fine with them using a web view for the chat display (even Apple does that, IIRC), but the wrapper interface, and especially the text input fields, should be Cocoa. NSTableView isn't that hard.

A better app would holistically encourage proper use. Slack does not. For example, what if we could schedule group chats? We schedule meetings (well, I hope we do). Group chat is just digital meetings. If all chats are just throwaway (metaphorically, it's all archived, of course!) private chats with only the people that need to be included, then we can schedule them for a specific time (with a Doodle-type scheduler, even).

SVN says this better than I can:

> It’s common in the software industry to blame the users. It’s the user’s fault. They don’t know how to use it. They’re using it wrong. They need to do this or do that. But the reality is that tools encourage specific behaviors. A product is a series of design decisions with a specific outcome in mind. Yes, you can use tools as they weren’t intended, but most people follow the patterns suggested by the design. And so in the end, if people are exhausted and feeling unable to keep up, it’s the tool’s fault, not the user’s fault. If the design leads to stress, it’s a bad design.

https://m.signalvnoise.com/is-group-chat-making-you-sweat-74...

The experience of Slack is horrid, IMO.

- Anyone can be interrupted at any time (to say nothing of @everyone), so it's essentially just an all-day meeting. At least emails could be responded to at relative leisure.

- There are only three notification states: "nothing" (normal icon) "something happened in a non-muted channel" (red dot), and "you were mentioned specifically". There's no way to gauge importance without disrupting your flow. Some pointless cat GIF (why are these being posted on work chat?) is ranked the same as "what should we do next?". Similarly, "@everyone there are donuts in the kitchen, OMG" is ranked the same as "@someone THE SERVER IS ON FIRE".

- Channels are never-ending, so it's relatively impossible to tell where one topic began and another ended. Additionally, multiple conversations can be held at the same time, and it's difficult to tell who's replying to who.

However, I quite like Slack's group private chats. I'd like to see a group-chat solution that promoted those and completely got rid of static channels. Everything's just a private group chat, with all of the people that are needed. When the discussion's done, archive it - it's searchable, of course, but if you need to continue the discussion, make a new one! Maybe everyone in the chat even gets a summary emailed to them that they can search in their email client as well (thus solving the "wait, where did we discuss that" problem).

There are a few other changes I would make - for example, the return key should be newline by default to prevent people from writing

like

this

and instead

putting their thoughts into well-composed

messages

Even those tasks are irritating on an iPad - outside of the limited multitasking, viewing multiple things at once is impossible. I can't look at an email and reference a website linked in it. I can't look at a few websites while composing an email. Comparing multiple travel booking sites side-by-side? Nope. If I try switching back and forth, the iPad has probably unloaded one of the tabs in the meantime due to memory pressure - why can't their state be archived to disk and loaded from that, at least?

It's interesting because for a very long time Apple said "maximizing is usually a waste of space" with the zoom button's behavior.

Looks like fenced blocks are part of the spec - will you be adding them to SO?

Why would this be a bad thing? I don't need a random number generator if I just want to allocate memory.

For example: http://www.scs.stanford.edu/histar/src/pkg/echo/echo.c

> Developers: less dependencies is better, especially when they're so simple!

No! The opposite of that. Lots of little µframeworks, defining composable and generic types, is much better than a giant monolith.

The Swift Package Manager is taking this approach, and I think it's great: https://github.com/apple/swift-package-manager#modules

The caret character doesn't appear anywhere in the semver spec, so whatever that does, it's non-standard: http://semver.org/

If your modules are small and well-defined, they probably won't need many versions anyways - they might just stay on 1.0.x forever. If you want to do something different, it might make more sense to just write another module.

I am not sure if there is a name for this type of function, so I called it someFunction:

    func someFunction<T>(initial: T, next: T -> T?) -> T
    {
        var current = initial

        while true
        {
            switch next(current)
            {
            case .Some(let value):
                current = value
            case .None:
                return current
            }
        }
    }

Now you can express that idea generally, e.g.:

    extension UIView
    {
        var rootView: UIView
        {
            return someFunction(self, next: { view in view.superview })
        }
    }

I also didn't test it, so it might not work.

Of course, it would be more Swifty to create a "Parentable" protocol and write that as an extension of it!

I tried to use Rust briefly but found that discovery was very difficult without autocomplete - I'm used to Swift's SourceKit, which is quite good if it hasn't crashed.

What happens if there is another bomb, after someone has reported as "safe"? Are the "safe" statuses updated somehow, since the state of that person is now unknown?

I can't see why anyone living in non-JMZ Williamsburg would renew their lease this year, unless they're biking regardless of weather conditions.

This doesn't prevent someone from just taking a pool towel to their room and then putting it in their suitcase.

Making the immutable version the same length as (or preferably, shorter than, e.g. Rust) the mutable version encourages the use of immutability.

If you're upset about Apple TestFlight, why not just use HockeyApp?

And https://github.com/apple/swift-package-manager once it's ready, which is similar to Carthage in structure (decentralized!).

This working environment looks like a cramped nightmare. How can anyone focus?

https://fortunedotcom.files.wordpress.com/2016/03/zap03-15_b...

Compared to, say the Basecamp offices, which look open, airy, and peaceful:

https://basecamp.com/about/office

Both Optional and Array have flatMap, i.e.

    T?.flatMap(T -> R?) -> R?
    [T].flatMap(T -> [R]) -> [R]

However, you cannot write a protocol for "things that can be flatMapped", because you cannot refer to a Self<T> specialized with a different type (Self<R>). With HKTs, you can do that, which would let you write something like this:

    protocol FlatMappable
    {
        typealias Value
        func flatMap<R>(Value -> Self<where Value == R>) -> Self<where Value == R>
    }

That's not useful on its own, but it means that you can now write functions and extensions that reason about the general concept of anything FlatMappable (this is most of the way to what is known as monads, FWIW).

Big things missing from Swift IMO:

- Higher-kinded types

- Strictly-typed "throw"

I'm not sure about dropping "Type" from protocols because it's pretty commonly used to separate the protocol definition (which is extended to provide most of the implementation) from the concrete base implementation, e.g. RAC's SignalProducerType/SignalProducer.

This is true. I tried to do something with Piston, but I couldn't figure out what the type of anything should be, because I could inspect functions to see what their parameter and return types were. I could follow examples, but they tended to use inline functions, which don't need to specify types.

In Swift you can just Cmd+Click to do this (assuming SourceKit hasn't crashed) and it's very useful for that kind of exploration.

Yes - for example, Linux distributions are notable for selling people into slavery.

A key difference is that MailChimp is invisible to the end recipient, while surveymonkey.com links are not.

All of those seem fine, except for "what last password do you remember", which is horrifying.

This question is also misogynist. My mother does not have a "maiden name" she has a "last name", which has always been the same. It's not the 1950s, women don't have to subjugate themselves to their husbands name anymore.

Oh, and gay people exist. Get with the times.

I got my options agreement which said I was entitled to N options at P price. No other information was provided, so not sure how I'm supposed to value them other than $0.

I assume that the options are intended for people that are bad at math.

Perhaps infant startups do not deserve "great talent". Engineers shouldn't have to give up cash for lottery tickets, especially when many founders won't even include the number of outstanding shares, preferences, etc. in the options agreement!

If startups do not want high turnover, they're free to offer above-market-rate salaries or a contract mandating a longer notice period on both sides. Overwhelmingly, they've chosen at-will employment instead.

It scares me that this could be used to justify stock options as having a value other than $0, and could be used to drive down real actual cash money salaries. I'm fine with the current situation because I have no plan to act on the options anyways - I don't invest in lottery tickets either.