Search Results

Search found 6 results on 1 pages for 'itchy'.

Page 1/1 | 1 

  • Eyes easily get dry and itchy [closed]

    - by Lo Wai Lun
    I have currently working as a programmer for half a year Very often, I often looking the monitors with natural contrast and brightness. Still when the weather is getting cold, my eyes feel dry and itchy. Sometimes I can see some red 'tree-roots' (capillaries) near iris. At home, i sometimes use my notebook for 13" or Galaxy Nexus Brightness are also natural contrast and brightness , a bit dim How should we take care of our eyes under this scenario?

    Read the article

  • How to use Xvfb in Ubuntu 14.04 with/without RandR?

    - by Itchy
    I try to run Unit-Tests with Selenium running Firefox on my Ubuntu 14.04 Server. And I'm using Xvfb as described in this blog to simulate a virtual display to show Firefox in. But Xvfg somehow doesn't load/work with RandR. Because whenever I try this: sudo Xvfb :10 -ac & export DISPLAY=:10 firefox I get an Xlib: extension "RandR" missing on display ":10"-Error. I've also tried sudo Xvfb :10 -ac +extension RANDR, sudo Xvfb :10 -ac -extension RANDR and beacuse it supplies with "xrandr" also apt-get install x11-xserver-utils. And my setup is a plain empty Ubuntu 14.04 Server with apt-get install xvfb firefox. Can anyone please help me run Xvfb with or without RandR?

    Read the article

  • Objective-C As A First OOP Language?

    - by Daniel Scocco
    I am just finishing the second semester of my CS degree. So far I learned C, all the fundamental algorithms and data structures (e.g., searching, sorting, linked lists, heaps, hash tables, trees, graphs, etc). Next year we'll start with OOP, using either Java or C++. Recently I got some ideas for some iPhone apps and got itchy to start working on them. However I heard some bad things about Objectice-C in the past, so I am wondering if learning it as my first OOP language could be a problem. Not to mention that I think it will be hard to find books/online courses that teach basic OOP concepts using Objective-C to illustrate the concepts (as opposed to books using Java or C++, which are plenty), so this could be another problem. In summary: should I start learning Objective-C and OOP concepts right now by my own, or wait one more semester until I learn Java/C++ at university and then jump into Objective-C? Update: For those interested in getting started with OOP via Objective-C I just found some nice tutorials inside Apple's Developer Library - http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/OOP_ObjC/Introduction/Introduction.html

    Read the article

  • Is there such a thing as "closure" with software work?

    - by Bobby Tables
    I burned out last year (after a decade of fulltime programming jobs) and am on a sabbatical now. With all the self-examination I've started to figure out some of the root causes of my burnout, and one of the major ones is basically this: there was never any real closure in any of the work I've ever done. It was always a case of getting into an open-ended support/maintenance grind and going stale. When I first entered the industry, I had this image of programming work being very project-based. And I expected projects to have a start, beginning, and END. And then you move on and start on something totally new and fresh. Basically I never expected that a lot (most) of software work involves supporting and maintaining the same code base for open-ended long periods of time - years and even decades. That, combined with generally having itchy feet makes me think that burnout is inevitable for me, after 2-3 years, in ANY fulltime software job. All this sounds like I probably should have been a contractor instead of a fulltimer. But when I discuss this with people, a lot of them say that even THEN you can't really escape having to go back and maintain/support the stuff you worked on, over and over (eg. Coming back on support contracts, for example). The nature of software work is simply like that. There is no project closure, unlike in many other engineering fields. So my question is - Is there ANY programming work out there which is based on short to mid term projects/stints and then moving on cleanly? And is there any particular industry domain or specialization where this kind of project work is typical?

    Read the article

  • Why shouldn't I always use nullable types in C#.

    - by Matthew Vines
    I've been searching for some good guidance on this since the concept was introduced in .net 2.0. Why would I ever want to use non-nullable data types in c#? (A better question is why wouldn't I choose nullable types by default, and only use non-nullable types when that explicitly makes sense.) Is there a 'significant' performance hit to choosing a nullable data type over its non-nullable peer? I much prefer to check my values against null instead of Guid.empty, string.empty, DateTime.MinValue,<= 0, etc, and to work with nullable types in general. And the only reason I don't choose nullable types more often is the itchy feeling in the back of my head that makes me feel like it's more than backwards compatibility that forces that extra '?' character to explicitly allow a null value. Is there anybody out there that always (most always) chooses nullable types rather than non-nullable types? Thanks for your time,

    Read the article

  • No More NCrunch For Me

    - by Steve Wilkes
    When I opened up Visual Studio this morning, I was greeted with this little popup: NCrunch is a Visual Studio add-in which runs your tests while you work so you know if and when you've broken anything, as well as providing coverage indicators in the IDE and coverage metrics on demand. It recently went commercial (which I thought was fair enough), and time is running out for the free version I've been using for the last couple of months. From my experiences using NCrunch I'm going to let it expire, and go about my business without it. Here's why. Before I start, let me say that I think NCrunch is a good product, which is to say it's had a positive impact on my programming. I've used it to help test-drive a library I'm making right from the start of the project, and especially at the beginning it was very useful to have it run all my tests whenever I made a change. The first problem is that while that was cool to start with, it’s recently become a bit of a chore. Problems Running Tests NCrunch has two 'engine modes' in which it can run tests for you - it can run all your tests when you make a change, or it can figure out which tests were impacted and only run those. Unfortunately, it became clear pretty early on that that second option (which is marked as 'experimental') wasn't really working for me, so I had to have it run everything. With a smallish number of tests and while I was adding new features that was great, but I've now got 445 tests (still not exactly loads) and am more in a 'clean and tidy' mode where I know that a change I'm making will probably only affect a particular subset of the tests. With that in mind it's a bit of a drag sitting there after I make a change and having to wait for NCrunch to run everything. I could disable it and manually run the tests I know are impacted, but then what's the point of having NCrunch? If the 'impacted only' engine mode worked well this problem would go away, but that's not what I found. Secondly, what's wrong with this picture? I've got 445 tests, and NCrunch has queued 455 tests to run. So it's queued duplicate tests - in this quickly-screenshotted case 10, but I've seen the total queue get up over 600. If I'm already itchy waiting for it to run all my tests against a change I know only affects a few, I'm even itchier waiting for it to run a lot of them twice. Problems With Code Coverage NCrunch marks each line of code with a dot to say if it's covered by tests - a black dot says the line isn't covered, a red dot says it's covered but at least one of the covering tests is failing, and a green dot means all the covering tests pass. It also calculates coverage statistics for you. Unfortunately, there's a couple of flaws in the coverage. Firstly, it doesn't support ExcludeFromCodeCoverage attributes. This feature has been requested and I expect will be included in a later release, but right now it doesn't. So this: ...is counted as a non-covered line, and drags your coverage statistics down. Hmph. As well as that, coverage of certain types of code is missed. This: ...is definitely covered. I am 100% absolutely certain it is, by several tests. NCrunch doesn't pick it up, down go my coverage statistics. I've had NCrunch find genuinely uncovered code which I've been able to remove, and that's great, but what's the coverage percentage on this project? Umm... I don't know. Conclusion None of these are major, tool-crippling problems, and I expect NCrunch to get much better in future releases. The current version has some great features, like this: ...that's a line of code with a failing test covering it, and NCrunch can run that failing test and take me to that line exquisitely easily. That's awesome! I'd happily pay for a tool that can do that. But here's the thing: NCrunch (currently) costs $159 (about £100) for a personal licence and $289 (about £180) for a commercial one. I'm not sure which one I'd need as my project is a personal one which I'm intending to open-source, but I'm a professional, self-employed developer, but in any case - that seems like a lot of money for an imperfect tool. If it did everything it's advertised to do more or less perfectly I'd consider it, but it doesn't. So no more NCrunch for me.

    Read the article

1