actf

To be clear, it doesn't support casting, which is what the previous commenter was asking for.

It runs directly on android tv. The app even says that there is no support for phones or tablets so casting isn't going to work.

I also agree that casting is the major missing feature from all these apps. Mirroring might be a substitute for some but, again to be clear, it isn't the same as casting and in most cases the quality is going to suffer significantly.

I've been very underwhelmed by the adaptive cruise control in my car as well. It was one of the features I was looking forward to the most, but in practice now I rarely use it. I'm also located in the pacific northwest, so I don't think highway design has anything to do with my complaints.

I find the braking is far too abrupt. I can see the car in front of me slowing down, but the system will continue accelerating until some magical distance threshold before it begins to brake.

In addition the follow distance doesn't seem to be dynamic relative to my speed. When I increase the follow distance, the car leaves too much distance at lower speeds, but increasing the follow distance causes tail-gating at higher speeds.

In my experience the problem is that when written as you describe them - user stories represent features and are rarely, if ever, granular enough that they represent a "thin vertical slice" of functionality - as scrum likes to call it. I've always felt this was something scrum did a poor job of addressing.

I have found that using user story format for epics or for features, and then further breaking those down into tasks seems to work quite well. Although as far as I'm aware there is no concept of a "task" in scrum. Task seems to be a Jira concept.

Yep, this is what got me hooked as well. I've also played using a PS4 controller using my laptop, and phone. I don't think the PS4 controller would work playing from the Chromecast though.

Stadia, the initial reviews were actually pretty bad, but I'm blown away by how good it is. There's something undeniably cool about playing cyberpunk on a macbook air with full graphical detail, and then switching over to play on my TV exactly where I left off. The latency is virtually imperceptible to me, and I love that I don't need a 50 GB download just to try out a new game. Everytime I use it I'm honestly impressed that it works as well as it does. My only concern now is whether I can trust Google not to eventually kill it, given their recent track record.

I personally love vim, and have found that setting up vim keybindings for my IDE seems like the best of all worlds.

I do appreciate the consistency and speed of plain vim, however I can't fathom trading that for code completion, which in my experience is the biggest missing feature from vim. Even with plugins like YouCompleteMe (which is awesome) the completion quality isn't even close to what you get in a real IDE. I'm honestly curious how people code productively in a professional environment without code completion?

This is a really good point. I would consider myself pro-union, but after considering what you just posted, I think you're right.

Thank you for the insightful comment, I feel like this may actually change some of my own opinions.

The first rule of DevOps is that if you have a DevOps team then you're not doing DevOps.

The SkyTrain is a great example of how easily transportation technology infrastructure fails during even slightly unexpected circumstances. The trains were inoperable for multiple times this past week, for hours at a time due to snow storms.

Trains aren't exactly new technology, yet here we are with them still not functioning properly during what was actually a pretty routine snow storm. It doesn't leave me very optimistic for self driving cars, which will be significantly more compliced technology.

> The military demands that soldiers immediately and unquestioningly follow commands given by their superiors (particularly during combat).

I don't think the way you've phrased this is quite accurate, although I understand what you're getting at.

In the book the author discusses how it is the responsibility of leaders to plan missions and to ensure that all voices and concerns are heard during planning. It's also the leader's responsibility to ensure that a decision about how to proceed is reached. Once a decision is reached though the expectation is that it will be carried out without question (I don't have any quotes handy unfortunately).

This sounds awfully similar to Amazon's principle of disagree and commit. I think this principle is congruent with the way the way the book suggests that leaders should operate.

From my own personal experience I think this is actually a really important principle. I find nothing more frustrating in a team environment than when one member of the team disagrees with a decision and decides to take it upon themselves to head off in their own chosen direction. It's very frustrating to have team members not following a plan.

Does anyone else find Qt difficult to setup/compile and find the qtmoc hoops that are necessary really frustrating when it comes to compiling projects in a non standard way?

I also really enjoy board spots in general, and I find there seems to be something unique about them that attracts introverts like myself, even though snowboard/board-sport culture can sometimes be a bit "bro-ey". I often find myself acting more extroverted and easily making friends while snowboarding/surfing/skateboarding.

I think it has to do with the simplicity, independent nature of board sports, and the self-reliant DIY attitude. There actually seems to be a lot of parallels to hacker culture, which is what I think makes it really unique when compared to other sports.

I'd really encourage others to try them, as they are a great way to get out of the tech bubble, make friends, and be active. They really aren't all that difficult to get started with. The learning curve is steep but short, and for the most part they aren't all that expensive.

I would be curious to know more about how you are doing this. Maybe Microsoft fixed this since I last used WSL, but if they didn't then you may be sitting on a ticking time bomb, see: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-n...

WSL is a great idea and I think Microsoft is onto something super cool with WSL, but after a week of serious use I found that it was not a viable replacement for cygwin. The major problem with WSL right now is that you can't effectively edit files in both Windows and WSL. For me this was very limiting because I could not interact with a git repo via WSL and then also open the files from that repo with a Windows IDE. In cygwin this would be no problem though.

I want to point out that this actually makes a great interview question.

I've had really good results asking this. I find it's a great question, because it allows the candidate to show off their knowledge, and use some knowledge that they likely prepared for ahead of time. I also like it because sometimes I get to learn something really interesting from the candidate.

It's also an easy way to filter people when they can't name even one algorithm, or their favorite is "that sorting algorithm"

Second this suggestion. As others have noted his books probably aren't going to win any literary awards, but they are fun entertaining reads. There are some similarities in subject matter to some of Dan Brown's books, but Russinovich is a former Microsoft employee (and iirc he wrote the sys intervals suite of tools) so his are much more technically detailed, and accurate then what you would find in Dan Brown.

> Of course, a lot is asked of engineers during crunch time, but that's the same way everywhere in the industry

I would like to point out that this is just objectively wrong. There are many employers in our industry that do not impose crunch time, and who view crunch time as indicative of poor engineering practices.

Maybe your statement came out wrong, but I was surprised enough when reading it that I felt compelled to let others know that this is not reality. There are lots of good employers that practice sustainable development practices in our industry.

Reading this thread, I'm having a very hard time understanding why anyone would want to work at Amazon (other then the somewhat high salary). Judging by responses to many of the parent comments, I'd say that others seem surprised as well. I hope this surprise reflects the abnormality of the practices described in this thread because they are not as common in the industry as you suggest.

I have looked at sciter and it looks pretty cool, but not being open source is a pretty major downside.

It sounds like your main concern is preserving the native look and feel of the OS.

I understand the argument, but I don't really understand the reasoning behind it. This is probably me being naive, but (assuming any performance problems are solved) the only reasoning I see to prefer native OS widgets would be to preserve compatibility with adaptive technologies (i.e. screen readers, OS keyboard shortcuts, high scale displays, etc), and to allow for automation of the UI.

Maintaining compatibility with adaptive technologies and allowing for automation both seem like good arguments to me. I think it would be challenging to solve those problems, but I think it could be done. Html already has mechanisms to deal with this, so I think another tool kit could take a similar approach.

Preserving the native look and feel however, doesn't seem nearly as important to me. I usually customize the look and feel of most desktop applications anyway. For example, changing the color scheme of my terminal, text editor, and IDE. I would hate it if I was forced to use the OS defaults. For example, on osx it's not possible to customize the look and feel of the iterm window, where as with hyper (an electron based terminal emulator) it is possible, and I find that I strongly prefer the later's UI (despite the electron performance issues). Even chrome allows me the ability to customize its UI. Of all the desktop applications I regularly use, there's very few these days that exclusively use the native OS widgets - at the moment evernote is the only one that actually comes to mind.

With some exceptions, users seem to manage pretty well on the web where every website already implements a different style of UI. For simple widgets like windows, buttons, textboxes, checkboxes, etc minor differences in style just don't seem like an issue to me. I think users will be able to visually identify a button even if it looks slightly different, and the advantage of allowing customization feels like a worthwhile tradeoff. For more complex UIs (like 3d renders, music editors, video editors, or games) most seem to already implement customized UI elements anyway.

What you're suggesting actually feels like a step backwards to me, so I'm genuinely interested to understand why you would want to maintain the same look and feel between applications? How do you currently customize the look and feel of your own environment?

I really like where the author went with this. Everytime I read something like this though I can't help but think how we as developers really need a better low level, UI framework for cross platform applications. What the author has done here is a cool idea, but ultimately this still feels flawed, and like it's a workaround to the difficulties of writing a cross platform UI. Everytime I read something like this I can't help but think about how great a low level, cross platform C (or C ABI) library would be (think something like libuv but for UIs). Such a library would abstract away the OS specific system calls of the UI while still providing the ability to easily do things like: * Create a window * Draw to the screen * Declaratively (i.e. html like) add UI widgets to a scene * Apply CSS like styling (like QML, JavaFX, or XAML) * Use native file dialogs, menus, notifications, etc * Statically link as a single dependency

I don't even think something like this necessarily needs to provide native UI elements, rather it just needs to be a more performant, easier to use, smaller, version of electron that could easily be used from any language. It needs to provide common UI elements like buttons, textboxes, divs, grid layouts, etc, but judging by the popularity of electron - I don't think those necessarily need to use native elements.

Qt is close to this, but it feels heavyweight and in my opinion its biggest flaw is that it's difficult to link to an application and setup a development environment for. Tk is kind of like this, but way too limited. JavaFX is a really good example, and would be perfect if it wasn't Java only (same with WPF but it's C# only). Right now the closest attempt to something like this that I know of is https://github.com/andlabs/libui

I think libui could even be a starting point for such a library, but the library I'm thinking of would need some type of declarative UI support (i.e. html like, maybe even support for a subset of html), built in support for styling, and less of a focus on using native widgets. I really wish somebody would build something like this.

> Still, people in dense cities who endure higher living costs tend to be happier

Most of the studies I've seen have said the exact opposite, that those living in urban environments are actually less happy: http://bit.ly/2v5cQni

Im sure you could save 50% of your after tax income, but I'm incredibly skeptical that you could do so while maintaining the same standard of living as the average plumber.

Regarding programmers doing remote work they are the exception, and probably account for 1-5% of all developers I would guess. Regardless, they are definitely not representative of the average developer - which is what we were discussing.

The problem with those statistics is that they don't account for location. Software developers may indeed make more salary than the average plumber, but to do so they're mostly required to live in a tech hub, with a high cost of living. I would hypothesize that to maintain a comparable standard of living (i.e. housing, food, etc) to plumbers their average disposable income would actually be lower.

I agree with what you're saying, but I also wonder, if not agile, then what do you see as a better alternative?

It sounds like you're suggesting that Agile methodologies have flaws that allow projects to be easily sabotaged. While I agree with this, I'm not sure I see an alternative? Is any development methodology going to be immune to this problem?

Human communication is messy, subjective, and open to all the imperfections that come along with the human condition. Unless you're working alone, any development methodology is going to be susceptible to "people problems". I don't see this as something that's unique to agile. I'm sure I could come up with hundreds of ways that idiocy, incompetence, and maliciousness could sabotage waterfall projects as well.

I'll second this, and also note that it probably make a good read for those who suggested reading Marshall Mcluhan (who the author references heavily).

Overall I enjoyed it, even though there were parts that I couldn't agree with.

I really enjoyed the book: Nonviolent Communication: A Language of Life by Marshall Rosenberg - which despite the title, is actually very relevant to this topic.

I picked it up after hearing a number of very positive reviews, and despite my skepticism, I now understand why it's so highly praised.

I'd try to provide a brief summary, but I know I wouldn't do it justice. I will however say that it's almost certainly one of, if not the best, book I've ever read on improving interpersonal communication and relationships.

The author has a phd in psychology, so the advice has some real science backing it up too.

Yea, I think this a really good idea.

I've also had the idea of an AirBnB for 'toys' (i.e. sports equipment, motorcycles, bikes, instruments, etc).

There is already RelayRides for cars, and qraft is probably the closest existing site to my idea, but I think it could be executed much better than qraft.

> One of the most impressive goals on the roadmap is to implement a terminal frontend as well as a QT frontend, which I'm quite excited to see.

I'm also interested to see this. I've said before that I think Go could be a really interesting language to develop GUI software in, however the existing QML package is "alpha quality". I've considered writing GUI software in Go, but at this point I think it would be a mistake given that most, if not all, GUI bindings in Go (and please correct me if I'm wrong) are considered experimental or alpha quality. In theory this will mean the author's progress will be somewhat dependent on the go-qml project, and may involve fixing bugs upstream.

If it were me, I would probably choose another language just based on the maturity of Go's current GUI bindings.

I haven't read the book you mention, but regarding a book that does cover c99/11, I really enjoyed: 21st Century C: C Tips from the New School

If you are an experienced C programmer you may end up skipping large portions of it.

In my opinion the book is mostly targeted at people that have had some C experience in the past (probably long ago in school) and have since moved on to newer languages. FWIW I read (and enjoyed) the book cover-to-cover, and I mostly do C# in my day to day work.

QML is awesome, and I'm a huge fan of it - and for that matter declarative GUIs in general.

However the QML-go project, while promising, is definitely not production ready. Their github page contains a large bold header that says: "this is alpha software", and it specifically warns about stability issues.

Also QML in general, has some shortcomings right now (granted those problems are being fixed) when using it for desktop software (specifically the lack of desktop style widgets).

So while I think the project is awesome and I'm wishing it success, I wouldn't want to use it for production quality software. I think my original point still stands.