Search Results

Search found 7 results on 1 pages for 'smp7d'.

Page 1/1 | 1 

• Good, simple reasons for having a multiple environments

  - by smp7d

  Throughout my career I had worked at companies that had a collection of different environments for different purposes. We always had more or less our desktop environment, a test environment, a QA environment, a staging environment and a production environment. This went for both servers/applications and any data sources we were using. When I started at my current company I found that 90% of the apps were either developed on a desktop environment against production data sources or developed directly on the production server depending on the platform. I wasn't phased because I was hired in part to make changes to improve the way the development team functioned, which was clear from my interview process. We slowly started to turn the philosophy and pretty soon, most of the apps could be run in either a desktop, test or production environment. Not too long after that staging came around as well. Now most of our developers see the benefit of this methodology and defend it vigilantly. However, we have a number of legacy apps that never got migrated. We also have a number of legacy programmers who think of this as a waste of time. Unfortunately, we got lip service but never full buy-in from management. We got what we thought was a commitment to invest substantially in this about a year ago, but nothing materialized despite the considerable planning that we put into it. Now we are finding that we need more and more environments. We need help from the server/network administration teams for setup and we need participation from the business stakeholders to support the release cycle. We are at a place now where a project can function what I consider "normally" only if you have the right people on the project and the time to set up the proper environments. I'd love to present a complete argument, but management really has no time and interest in hearing me out until there is a critical issue. I cant really articulate the benefits simply as it always just seemed second nature to me. I was wondering if there are any good, simple, irrefutable reasons for the separation of environments that would get managers with no development experience to get behind this idea. Are there any good resources/literature on the topic?

  Read the article

• Diminishing Returns on Additional Developers

  - by smp7d

  Is there a term to describe the point at which adding more developers to a software project will provide diminishing returns? I realize that at a high level, it is more complicated that just a number of developers at which the project will be at productive capacity (ex/ state of the project, quality of the added developer), but I am trying to come up with a way to relate this to non-technical management through repetition. I'm basically looking for a term which invokes a strong image like "terminal velocity", except for Brook's Law.

  Read the article

• Good, simple reasons for having multiple environments

  - by smp7d

  Throughout my career I had worked at companies that had a collection of different environments for different purposes. We always had more or less our desktop environment, a test environment, a QA environment, a staging environment and a production environment. This went for both servers/applications and any data sources we were using. When I started at my current company I found that 90% of the apps were either developed on a desktop environment against production data sources or developed directly on the production server depending on the platform. I wasn't fazed because I was hired in part to make changes to improve the way the development team functioned, which was clear from my interview process. We slowly started to turn the philosophy and pretty soon, most of the apps could be run in either a desktop, test or production environment. Not too long after that staging came around as well. Now most of our developers see the benefit of this methodology and defend it vigilantly. However, we have a number of legacy apps that never got migrated. We also have a number of legacy programmers who think of this as a waste of time. Unfortunately, we got lip service but never full buy-in from management. We got what we thought was a commitment to invest substantially in this about a year ago, but nothing materialized despite the considerable planning that we put into it. Now we are finding that we need more and more environments. We need help from the server/network administration teams for setup and we need participation from the business stakeholders to support the release cycle. We are at a place now where a project can function what I consider "normally" only if you have the right people on the project and the time to set up the proper environments. I'd love to present a complete argument, but management really has no time and interest in hearing me out until there is a critical issue. I can't really articulate the benefits simply as it always just seemed second nature to me. I was wondering if there are any good, simple, irrefutable reasons for the separation of environments that would get managers with no development experience to get behind this idea. Are there any good resources/literature on the topic?

  Read the article

• Do extra words in url affect SEO?

  - by smp7d

  Often for technical reasons we end up with some extra words in a url that we would not want to optimize for as they would have no bearing on the content. Examples would be: sportssite.com/content/sports-article movieportal.com/node/movie-review electronicsforum.com/blog/top-10-cameras webmasters.stackexchange.com/questions/34046/do-extra-words-in-url-affect-seo Do these have any affect on ranking in any of the major search engines? Would it behoove us to strip the extra words?

  Read the article

• Office lights on or off in programming department? How to decide? [closed]

  - by smp7d

  At my company, the programmers who sit in the same area are constantly fighting over whether the lights stay on or off. Because there is no official policy it makes it a particularly sticky situation. We are a typical cube-farm and we have those typical cube-farm fluorescent lights and smaller ones at our desks. With the lights off, it is difficult to read and you would probably need to turn on your desk light (which some people do anyway). All programmers in our department do most of their reading on their monitor because of the nature of our business. Some feel that we should have a vote to decide whether the lights stay on or off. A couple who prefer 'lights on' feel that the vote would need to be unanimous to turn them off as having them on is the more natural office setting. Those who want them off point out that all other departments keep their lights off. I have heard all of the arguments: -Fluorescent lights cause eye strain -Reading in dark causes eye strain -The desk lights can be used if light is needed -People from other departments feel uncomfortable approaching us in the "dark" -The monitors are harder to see in the light ... Right now, some of the developers turn off the lights and some turn them on. It really just depends who last walked by the switch. I am a bit sick of the controversy as it feels a bit childish at the moment. I'm tired of hearing about it and I'm tired of having to talk about it. I tried to help them decide but as I explained, voting wasn't enough. Do other programming departments have this same argument? What is the standard or traditionally accepted option in a programming area? Are there any good reasons for one way or the other outside of preference? How can we decide fairly? EDIT Just a little more info... We do not have clients/visitors come into our office. We do have windows and hall lights that make our environment plenty bearable with the lights off. It kind of resembles a meeting room that has the lights off during a powerpoint presentation.

  Read the article

• Using mocks to set up object even if you will not be mocking any behavior or verifying any interaction with it?

  - by smp7d

  When building a unit test, is it appropriate to use a mocking tool to assist you in setting up an object even if you will not be mocking any behavior or verifying any interaction with that object? Here is a simple example in pseudo-code: //an object we actually want to mock Object someMockedObject = Mock(Object.class); EqualityChecker checker = new EqualityChecker(someMockedObject); //an object we are mocking only to avoid figuring out how to instantiate or //tying ourselves to some constructor that may be removed in the future ComplicatedObject someObjectThatIsHardToInstantiate = Mock(ComplicatedObject.class); //set the expectation on the mock When(someMockedObject).equals(someObjectThatIsHardToInstantiate).return(false); Assert(equalityChecker.check(someObjectThatIsHardToInstantiate)).isFalse(); //verify that the mock was interacted with properly Verify(someMockedObject).equals(someObjectThatIsHardToInstantiate).oneTime(); Is it appropriate to mock ComplicatedObject in this scenario?

  Read the article

• Eclipse: Double semi-colon on an import

  - by smp7d

  Using Eclipse, if I have an extra semicolon on an import line (not the last import line), I see a syntax error in the IDE. However, this compiles fine outside of the IDE (Maven in this case). Example: import java.util.ArrayList;; //notice extra semicolon import java.util.List; Does anyone else see this behavior? Why is this showing as a syntax error? I am working with someone who keeps pushing these this to source control and it is irritating me (they clearly aren't using Eclipse). Full disclosure... I am using SpringSource Tool Suite 2.8.0.

  Read the article

1