I remember trying multiple solutions with exception files and such but not having a lot of luck at filtering the ones I did not care about while keeping my own errors displayed. It's clearly user error on my end but I always gave up and rewrote smaller samples without external dependency when I could.
I read this book last year and my favourite interview was Steve Perlman's, the founder of WebTV (http://en.wikipedia.org/wiki/Steve_Perlman). I was amazed at the things they did at Catapult Entertainment (http://en.wikipedia.org/wiki/XBAND). And even more amazed to discover he also founded OnLive even if it did not work out in the end.
I was also blown away by Mike Lazaridis' stories about RIM especially when reading it so many years after the iphone/android launch.
I love valgrind and it saved my ass countless time when tracking memory leaks or overflows. The main issue I've always had with it is filtering the output easily. When you use external libraries (portaudio or Qt for example but also proprietary libraries I had to use at work) a lot of the debug messages pollute what is really yours and your leak is then a needle in a haystack.
I've encountered a lot of issues on Windows XP with QT/Angle but also quite a lot on Windows Vista/7 where the graphic drivers by default don't support properly OpenGL or pretend they do but don't answer properly to Qt's requests. This ended up with a big chunk of my users having a blank window or even no window displayed to them and no way to reliably detect this on our end.
This feature has been in the works for multiple months now and I'm really glad to finally see it ship officially with Qt 5.4, so congrats to the team!
I did not understand the sentence that way even after reading multiple times but that seems to make sense now. I must have been too biased when reading it before. Thank you for pointing this out.
Sorry if I wasn't clear enough. What I mean is that if in 3 years my company needs to have access to some logs, they will have to go through the multi-steps process but then have access to whatever they need (starting from today's logs)
What I meant was that the possibility to access private chats should stay not retroactive and only happen once the company has explicitly stated it will need this feature enabled.
EDIT: so that if my company has no legal needs today it won't have access to private chats made today once they decide in the future that they now need the feature
What I don't understand is why not have this be "opt-in". Meaning if your company does not need this feature for real legal reasons they don't enable it and everyone is happy. I've heard a few people saying they did not want this feature in Hipchat and would have to switch to make sure there team was not suspicious. If my company never needs to access private chats for legal reasons, there is no reason it should be enabled today and they can have access to it in 3 years.
I understand specific companies have specific needs and Slack has to meet some of these but there is no reason that this should impact everyone else.
You could say they just learnt from the Hipchat announcement and remebered to address the issue head-on which makes it seem like they really care. But in the end the problem is exactly the same and your company will now have access to whatever you write including private chats. Personally that means I'll ensure to avoid private chat on Slack and use external tools again on top of everything I already use which is clearly annoying.
When I look for a job I apply to multiple companies at the same time when I find job openings that match what I'm looking for and also apply to companies I'd love to work for that don't have openings.
So I end up having multiple phone interviews and then on-site interviews until I get one or more good offers. Just recently I got 3 really good offers in the span of two weeks and took the time to chose the one I really wanted to accept. I told each company I was interviewing at other places too and wanted some time to think.
That's a question I'm clearly interested in! I just moved to another country and am working on a website to play my favourite board games with my family and was wondering if I could publish it on github or if I should keep this private as I don't have the rights for the board game.
I understand how you handle it on your end but let's assume I decide to build an API for a language you don't support yet. In a few months when you add new versions of the API where some fields become optional or mandatory, then won't I have to know all this as the library developer and handle each case? Because some of my users would expect to still be able to send the charge amount while others would not.
I'm more thinking in the idea of doing some "pre-validation" in my library to avoid an API call from the client when something is already expected to fail (like missing the amount field right now) which would not fail with a new version of the API. So I would have to adapt to each version to know that this user would require the amount field while another one would not.
Does it also mean that when doing an API client library for stripe you have to handle all this complexity about versionning? Because if someone updates to the latest version of the library but still wants to use the old way of creating a charge (staying on the example where charge would now always be 1$) he would want to be able to do it without having to find an older version of the library that supported this API version.
Was gonna say this now that I've seen it work! From a first inspection this makes me think of producthunt but maybe for projects in progress or not launch-ready?