Depends on what you use it for. For project communication my teams have found it absolutely indispensable. There is a middle ground, but it requires active channel management, creating channels with the right size of audience to be useful. I have found that small, focused channels generally work better for projects. Weâ(TM)ll create topic specific channels for a short time, then archive them when no longer needed. It means having a larger number of smaller channels over a few big ones. I have found using @ mentions to specific people when you need a response very useful to keep away from the noise of @here and @channel.

Sametime died a slow death as Slack usage picked up. I stopped using it as my primary messaging client 2-3 years ago and last year stopped even bothering to launch it. It became a ghost town, only people in shared corporate services seemed to use it. Now even they seemed to have largely drop Sametime. It was just a matter of time before Sametime died entirely within the company.

We have corporate-written best practice write ups which the newbies quickly get pointed to. They answer a lot of the questions such as how to handle confidential info, channel sharing, naming conventions and such. There is a shared slack channel that I believe all users have access to for common questions on slack usage. It gets used a lot and is actively moderated to give guidance on thread usage and etiquette.

The challenge is with all the workspaces. Typically we have a dedicated project-specific workspace for mid to large consulting projects to keep things contained and allow project-specific admins to manage things. I have probably a dozen other workspaces but mostly there are two I use on a daily basis. I mute notifications from most shared channels to keep things sane.

The plethora of admins are needed to manage things, they are given a lot of autonomy for their workspaces, but etiquette rules such as bot installation get hammered into everyone pretty quick, but with multiple workspaces we keep from having one fits all kind of setup for the most part, with the exception of certain actions managed at an enterprise level in order to adhere to corporate standards on security and confidentiality.

That is in fact what it does

There is that period of time, usually for around 3 seconds or more, when a plane hovers just a few feet above the runway before finally making contact. During that time, if you are not already turning to match the runway curvature, you would have to improbably make wheel contact at the exact tangent point, all the while clearing the lip of the banked runway. There is no way in my view of having a safe landing without first matching the curvature before touching down.

From what I see in the documentation, the "guard let" combination is sort of the opposite of "if let". Normally you would have something like this which would both assign destinationViewController to a new constant and would check to see if the result of controller is nil:

if let controller = segue.destinationViewController { // do something with controller
}

with guard you can do the opposite:

guard let controller = segue.destinationViewController else { // handle a controller that contains nil
      return nil
}

You can also use it to check a complete expression for errors. The following will check if someController is nil OR someController.bunchOfItems is nil OR someController.bunchOfItems.count == 0

guard someController.bunchOfItems.count > 0 else {
        throw MyError.OutOfStock
}

The guard statement is used for error management, and must transfer control using return, throw, break, or continue from within the block

From the author's bio: "He is having immense interest in psychology, human behavior and mind hacks."

Given that as well as the bad grammar, I'm pretty sure this is made up to get a reaction.

Perhaps fine for Roman characters, not so fine if the document contains Kanji, Hiragana, Katakana, Hebrew, or any of the other character sets that don't play nice with "plain text" formats. For something that you would think would be pretty straight forward, plain text character handling is surprisingly maddening to work with.

I went through my university's co-op program, which was the best thing I ever did in my university experience. I highly recommend trying out a job in your field of interest before graduating, it's a great tool to focus the rest of your schooling.

Yep, Frontpage code was a mess, and it messed up stuff that was added by hand. So annoying.

I think it also had a "Fix HTML from Microsoft Word" option. Word should never have gotten an export to HTML option, although I imagine that the HTML output it created back then was likely not far off from what it must have looked like in the .doc file itself. If so, that would explain a few things.

Ick, I stayed far, far away from that tool. I've worked with the markup that it's generated and it wasn't pretty. Then again, I've also worked with markup hand coded from people who weren't familiar with HTML/CSS best practices (even very recently), and it was equally painful to get the page to a level where I wouldn't cringe looking at the markup. Ultimately, whatever tool you use, it's no replacement for experience.

That's not been my experience with Dreamweaver for a long time, and I've been using it since version 3 in 1999. Back then it was one of the cleanest HTML editors out there and since then I think they've done a decent job of keeping it clean and keeping it from messing up markup you've added by hand. The issue that I see with how cruft is created in an HTML editor is from lack of familiarity with the raw HTML and CSS. For instance, if you just go ahead and start setting display properties on an element, it's going to put it inline or in a style embedded on that page. You have to at least know to set up an external stylesheet and how to link those styles to elements on that page to prevent that kind of cruft from forming. Also it makes a big difference to work in Dreamweaver's split code/design view, so that changes in one panel immediately show in the other. I've been coding by hand for a long time, but I still like having this view as it gives me confirmation that the page is structured the way I intended.

A couple of options. One, you could probably bundle the files up into an app like one created using PhoneGap, which would make everything local. Two, you could set the proxy setting to point to a server that you control, that will direct you only to an internal web server that you control. Regardless of how you do it, you will need to physically block the power and home buttons, and for non-iPad tablets, any other button that might take you home like the back button with something like a lockable case. Seems silly to block the internet, though, considering how many people in that waiting room are going to be browsing with their iPhones anyways.

Or you could say that with the sensor smaller than the projected image you get the benefit of some extra optical zoom. You're not going to see significant degradation just because some of the light coming in is not used, there are plenty of photons coming in to get a nice sharp image from a 1:1.6 sensor. Such a sensor is still large enough that it doesn't suffer from the signal to noise issues in the very small and very high density sensors that are in many point and shoot cameras, so you are probably going to get a less noisy image in a partial frame sensor in a DSLR than you might get in a 15MP point and shoot.