Subscribe: Matt Watson
Added By: Feedage Forager Feedage Grade B rated
Language: English
access  application  developers  development  geekswithblogs net  iis  log files  log  net  problems  stackify  support  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Matt Watson

Matt Watson

Software developer, product visionary, and master of #dadops

Copyright: Matt Watson

Stackify Prefix review

Sat, 28 Jan 2017 12:01:24 GMT

Originally posted on: Prefix – The best profiler to write better software Writing a software and Troubleshooting has never been easy. Quick feedback loops in workflow reduces the burden of checking the validity in a specific code segment or a program that we write. It is obvious that when a problem or an error is informed then and there, that it becomes very much easier to handle. Without a quick feedback loop it becomes tedious to solve the issues as the initial mindset of the problem has already passed. Although it was a concept made popular by the agile methodology and practices, it’s something that most of us deal with when we invoke the compiler towards the latter part of programming. Profiling and performance testing has always been a process that is invoked towards the end of a program. What I usually face is that it address a very common problem or stress a testing scenario. Using Stackify as an profiler is one of the best options that I have come across and I would highly recommend when it comes to profiling. The remarkable thing about Stackify profiler is that it is not just a profiler but a product which displays details per web request, so it often gives the eligibility understand what your code is doing currently and how long it takes to perform. Apart from that Prefix will help you troubleshoot what your code is doing by inspecting key methods, database queries, web service calls, and logging statements etc…, Installing Stackify Prefix  Unlike any other .Net profilers prefix is very easy to install and has both free and premium levels. Simply after the installation process one can check for it’s functioning by following the simple steps mentioned below. ·        Restart your PC. ·        From the tray app, right click on it and click "Disable Profiler" then "Enable Profiler" once it stops. ·        Start Visual Studio as an administrator. ·        Debug your application as normal.  With these simple steps the most useful ASP.NET profiler is started to function.  Overview of Stackify Prefix After the installation process what the Stackify prefix do is, it attaches itself to IIS or IIS Express and displays information about each web request. This web request information simply has the following content and the mentioned details are displayed as shown in the Image. 1.       The total time it took to serve the page 2.       The number of database requests 3.       Details about the caught exceptions 4.       The status of code When we dig down further more information related to the web request the following also could be viewed. ·        The Raw HTTP request information ·        The actual SQL queries which are actually being run ·        Exception and stack trace information along with the performance ·        Timings for each stage of execution Key features of Stackify Prefix Apart from the above mentioned functionalities related to requests some remarkable techniques that Stackify follows is that it gives you the ability to views your log’s request one by one at a time. Also it helps you find the hidden exceptions in the program which are often unnoticed. In a situation where your program works abnormal, it spots the suspicious behaviors in the program. And not only that, it also gives the eligibility to view the SQL commands which makes programming a software lot more convenient. The Premium version of Stackify Prefix comes with another sensational set of features. Tracing transactions across servers to get remote server details real-time, Instantly monitoring and comparing the computer performance, Suggestions to make your code smarter and Tracking any method prevailing in your code are some of them. All in all when we compare the full package of Stackify Prefix, it accomplish the following tasks in an efficient and striking way.  ·        It helps you find slow SQL queries, w[...]

Application Insights – 16 things every developer needs to know

Tue, 24 Jan 2017 12:06:31 GMT

Originally posted on:

Application Insights is Microsoft’s lightweight application performance monitoring service. I have collected a nice list of things that every developer should know. Including tips, key features, and limitations.

1. Make sure your app targets .NET 4.6, and .NET 2.0 is not supported
2. Warning! Sensitive data is not scrubbed from dynamic SQL queries
3. Key limitation: Finding slow SQL queries
4. SQL query times are not always correct
5. Azure App Services require a site extension for all features
6. View top exceptions in your application
7. Asynchronous HttpClient calls are not supported
8. Tracking application dependencies
9. View all details for a single web request (transaction trace)
10. How to Identify why a request or entire application is slow
11. Monitoring & Alerts features and limitations
12. Reporting across applications
13. No support for the concept of multiple “environments” (QA, Prod, etc)
14. App Insights is not a code profiler
15. Application Insights has a robust API, and you will likely need it
16. How to use Application Insights with Windows Services


Log files to know about to find failed ASP.NET requests

Sat, 21 Jan 2017 21:51:40 GMT

Originally posted on: web application is throwing some sort of error or invalid response. Do you know how to troubleshoot IIS or ASP.NET errors on your servers? Luckily, Windows & ASP.NET provide several different logs where failed requests are logged.You are probably familiar with normal IIS logs, but there are some other places to look if you are looking for more detailed error messages or can’t find anything in your IIS log files.1. Standard IIS LogsStandard IIS logs will include every single web request that flows through your IIS site. Via IIS Manager you can verify that your IIS logs are enabled and where they are being written to. You should find your logs in folders that are named by your W3SVC site ID numbers.By default each logged request in your IIS log will include several key fields including the URL, querystring, and error codes via the status, substatus and win32 status. These status codes can help identify the actual error in more detail.#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken 2016-09-13 21:45:10 ::1 GET /webapp2 - 80 - ::1 Mozilla/5.0 - 500 0 0 5502 2016-09-13 21:45:10 ::1 GET /favicon.ico - 80 - ::1 Mozilla/5.0 http://localhost/webapp2 404 0 2 4The “sc-status” and “sc-substatus” fields are the standard HTTP status code of 200 for OK, 404, 500 for errors, etc. The “sc-win32-status” can provide more details that you won’t know unless you lookup the code. They are basic Win32 error codes.2. Can’t find your request in the IIS log? HTTPERR is your IIS error logEvery single web request should show in your IIS log. If it doesn’t, it is possible that the request never made it to IIS, or IIS wasn’t running. Also, be sure that your IIS logging is enabled.Incoming requests to your server first route through HTTP.SYS before being handed to IIS. These type of errors get logged in HTTPERR. Common errors are 400 Bad Request, timeouts, 503 Service Unavailable and similar types of issues. The built in error messages and error codes from HTTP.SYS are usually very detailed.Where are the HTTPERR error logs?C:\Windows\System32\LogFiles\HTTPERR3. Look for ASP.NET exceptions in Windows Event ViewerBy default ASP.NET will log unhandled 500 level exceptions to the Windows Application EventLog. This is handled by the ASP.NET Health Monitoring feature. You can control settings for it via system.web/healthMonitoring in your web.config file.Very few people realize that the number of errors written to the Application EventLog is rate limited. So you may not find your error! By default it will only log the same type of error once a minute. You can also disable writing any errors to the Application EventLog. Still can’t find your exception?Depending on if you are using WebForms, MVC, Web API, WCF or other frameworks, you may have issues with ASP.NET not writing any errors at all to ASP.NET due to compatibility issues with the health monitoring feature. 4. Enable Failed Request Tracing for an advanced IIS error logFailed request tracing (FRT) is probably one of the least used features in IIS. It provides robust IIS logging and works as a great IIS error log. FRT is enabled in IIS Manager and can be configured via rules for all requests, slow requests, or just certain response status codes.The only problem with FRT is it is insanely detailed. It tracks every detail and every step of the IIS pipeline. You can spend a lot of time trying to decipher a single request.This article is based on a post from Stackify's blog: Beyond IIS logs – 6 ways to find failed IIS/ASP.NET requests [...]

ASP.NET Performance Tracking Tools

Sun, 06 Dec 2015 15:50:07 GMT

Originally posted on:

Stackify just published a great blog post about all the different ways to track the performance of your ASP.NET apps. Including code profiling, IIS logs, application performance management, glimpse, RUM, APM tools, Application Insights, and more!

"One of the best things about being a .NET developer is all the amazing development tools that can make your life easier. This blog post is a list of the various types of tools at your disposal for finding and optimizing performance problems. Depending on the task, some of these tools will be much better than the others."


DevOps – A Valentine’s Day Fairy Tale

Wed, 13 Feb 2013 21:39:10 GMT

Originally posted on: upon a time two people from different sides of the tracks met and fell in love. Never before had the two people found another person who so perfectly complemented them. Society tried to keep them apart – “It’s just not how things are done,” they’d say. But times were changing, and this sort of pairing was becoming more socially acceptable.They met at the perfect time.Ops had grown tired of the day to day grind of solving other people’s problems. Enough was enough and she needed a change in her life.  A perfectionist and taskmaster to the highest degree, she tended to be very controlling and possessive in relationships. It became more about commands than conversation, making life miserable for both parties. She began to realize she hated change, and felt like she spent most of her time saying “No.” It was time to open up and begin to share to make a relationship work.Dev, on the other hand, was beginning to mature (a little late in the game, as guys seem to) and trying to find some direction. He had grown tired of communication breakdowns in relationships – angry phone calls in the middle of the night, playing the blame game, and his inability to meet halfway on anything. He began to realize most of those angry phone calls came as a result of making impulsive decisions without considering how they would impact others. His bad decisions commonly led to performance problems and created a mess for his partners. Dev wanted to more actively seek out everything that makes a healthy relationship work.The timing was right for a match made in heaven. Dev and Ops openly working and living side by side to make sure both contributed equally to making their relationship work. Ops realized she didn’t have to be so controlling if she and Dev could build trust between one another. Dev realized that he caused fewer fights if he involved Ops in decisions about the future, since those decisions impacted both of them. It was a growing process that caused a lot of rapid and sudden change. Although, like most relationships, they knew it was important to not move too fast, no matter how good it felt.Dev and Ops dated for about four years before they decided to get married. Now they will be living together and sharing so much more; will their relationship last? How will it need to change to support the additional closeness? But they aren’t worried, they know it is true love and will do whatever it takes to make it work. Relationships are always hard, and they know they can solve most of their problems with a reboot, hotfix, or patch cable.Will you accept their forbidden love?7 Reasons the DevOps Relationship is Built to LastFaster development and deployment cycles (but don’t move too fast!)Stronger and more flexible automation with deployment task repeatabilityLowers the risk and stress of a product deployment by making development more iterative, so small changes are made all the time instead of large changes every so oftenImproves interaction and communication between the two parties to keep both sides in the loop and activeAids in standardizing all development environmentsDevOps dramatically simplifies application support because everyone has a better view of the big picture.Improves application testing and troubleshooting [...]

The Golden Rule of Programming

Fri, 18 Jan 2013 13:13:56 GMT

Originally posted on: published on is one particular issue that seems to be the root of most bugs in software programs. I see it over and over and over. Like most programmers, it has caused me heartburn since the day I started programming. So I have worked hard to make sure that my code never breaks my golden rule. So now I remind my development team every chance I get to also follow what I call the golden rule of programming. I think every new programmer needs a tatoo that says it.So what is the golden rule of programming?"If it can be null, it will be null"Null reference type errors are responsible for a good percentage of all application bugs. They are usually very simple problems. Typically caused by not adding additional logic to ensure that objects have valid values before using them.How about some simple examples of null values causing problems?Here is a classic example below. A string variable passed in to a method is used before ensuring it isn't null. KA-BOOM!public void DoSomething(string text) { if (text.ToUpper() == "Hello World") { //do something } }One of the most common causes is settings, database calls, or API type calls not returning expected values. For example, you add a new field to your database and don't populate default values for every record. Randomly records get queried and the code didn't account for that new field being null. KA-BOOM!The good news is that a lot of null reference errors can be avoided by adding additional logic and code to ensure objects are not null before trying to use them. Developers should always assume that everything is FUBAR and be very defensive in their code. Pretend every database call is going to fail, every field is going to have messed up data in it.Some tips to prevent null reference exceptions:Initialize variables with valid values.If a variable can be null, then check for null and handle it appropriatelyFor C# use the ?? operator with strings when appropriate. ex. (stringvar ?? "").ToUpper()If you follow my golden rule, I promise you will have far fewer bugs in your apps. Because if it can be null, it will be null! [...]

What is the Ops in DevOps?

Wed, 16 Jan 2013 16:43:29 GMT

Originally posted on: what does DevOps mean exactly? What is the Ops in DevOps?  Operations can mean a lot of things and even different things to different people. DevOps is becoming more and more popular but I also think a lot of people are confused to exactly what it is. So let’s make a list of all the things operations does and figure out what developers should be doing, and not doing.Operations responsilibitesIT buying decisionsInstallation of server hardware and OSConfiguration of servers, networks, storage, etcMonitoring of serversRespond to outagesSome other dutiesIT securityManaging phone systems, networkInternal help desk supportChange controlBackup and disaster recovery planningManage active directoryAsset trackingShared Development & Operations dutiesSoftware deploymentsApplication supportSome of these responsibilities have changed a lot in the last few years. Virtualization and the cloud have greatly simplified buying decisions, installation, and configuration. For example, nobody cares what kind of server we are going to buy anymore for a specific application. We buy great big ones, virtualize them, and just carve out what we need and change it on the fly. Cloud hosting simplifies this even more by eliminiating the step of buying a great big server.So what part of the Ops should developers do?Be involved in selecting the application stackConfigure and deploy servers (potentially)Deploy their applicationsMonitor application and system healthRespond to applications problems as they arise.In my opinion, that is the lifecycle of DevOps. Select the application stack, build it, deploy it, support it. The developers basically own the stack from operating system and up. If you have 5 development teams working on different projects, it makes a lot of sense for each team to be responsible for all of these things from start to finish. Make the developers completely responsible for their own application. Operations can simply be responsible for the physical infrastructure that supports it.So what does the operations team do then?Manage the hardware infrastructureConfigure and monitor networkingEnforce policies around backup, DR, security, change control, etcAssist in monitoring the systemsManage active directoryAsset trackingOther non production application related tasksIf your IT department is small, one of your developers can easily handle all of these tasks. In larger companies though I’m sure this role will be around forever. But… If you are using cloud based hosting, do you need operations at all? If you are embracing the DevOps concept of developers owning the deployment and production support of their applications, and you are using cloud hosting, you could probably say you are doing NoOps in your data center. But you still need at least a help desk person in the office to support your internal desktops.DevOps to me is the concept of letting the operations team provide the hardware and letting the developers basically own everything from the OS up. Select the application stack, build it, deploy it, support it.What do you think developers should do or not do? [...]

Kauffman Foundation Selects Stackify to Present at Startup@Kauffman Demo Day

Fri, 09 Nov 2012 13:16:53 GMT

Originally posted on:

Stackify will join fellow Kansas City startups to kick off Global Entrepreneurship Week

On Monday, November 12, Stackify, a provider of tools that improve developers’ ability to support, manage and monitor their enterprise applications, will pitch its technology at the Startup@Kauffman Demo Day in Kansas City, Mo. Hosted by the Ewing Marion Kauffman Foundation, the event will mark the start of Global Entrepreneurship Week, the world’s largest celebration of innovators and job creators who launch startups.
Stackify was selected through a competitive process for a six-minute opportunity to pitch its new technology to investors at Demo Day. In his pitch, Stackify’s founder, Matt Watson, will discuss the current challenges DevOps teams face and reveal how Stackify is reinventing the way software developers provide application support.

In October, Stackify had successful appearances at two similar startup events. At Tech Cocktail’s Kansas City Mixer, the company was named “Hottest Kansas City Startup,” and it won free hosting service after pitching its solution at St. Louis, Mo.’s Startup Connection.

“With less than a month until our public launch, events like Demo Day are giving Stackify the support and positioning we need to change the development community,” said Watson. “As a serial technology entrepreneur, I appreciate the Kauffman Foundation’s support of startup companies like Stackify. We’re thrilled to participate in Demo Day and Global Entrepreneurship Week activities.”

Scheduled to publicly launch in early December 2012, Stackify’s platform gives developers insights into their production applications, servers and databases. Stackify finally provides agile developers safe and secure remote access to look at log files, config files, server health and databases. This solution removes the bottleneck from managers and system administrators who, until now, are the only team members with access. Essentially, Stackify enables development teams to spend less time fixing bugs and more time creating products.

Currently in beta, Stackify has already been named a “Company to Watch” by Software Development Times, which called the startup “the next big thing.” Developers can register for a free Stackify account on
Founded in 2012, Stackify is a Kansas City-based software service provider that helps development teams troubleshoot application problems. Currently in beta, Stackify will be publicly available in December 2012, when agile developers will finally be able to provide agile support. The startup has already been recognized by Tech Cocktail as “Hottest Kansas City Startup” and was named a “Company to Watch” by Software Development Times. To learn more, visit and follow @stackify on Twitter.

Windows Server 2012 Enable RDP

Fri, 09 Nov 2012 13:10:29 GMT

Originally posted on:

After installing Windows Server 2012, one of the first things you likely need to do is enable RDP. Thanks to the Metro UI, things are a little different...

From command line go to SystemPropertiesRemote

Or right click bottom left corner and go to System, then Advanced System Settings, Remote tab

Here is a good article with more details if needed


Getting developers and support to work together

Tue, 16 Oct 2012 02:01:20 GMT

Originally posted on:

Agile development has ushered in the norm of rapid iterations and change within products. One of the biggest challenges for agile development is educating the rest of the company. 

At my last company our biggest challenge was trying to continually train 100 employees in our customer support and training departments. It's easy to write release notes and email them to everyone. But for complex software products, release notes are not usually enough detail. You really have to educate your employees on the WHO, WHAT, WHERE, WHY, WHEN of every item. If you don't do this, you end up with customer service people who know less about your product than your users do. Ever call a company and feel like you know more about their product than their customer service people do? Yeah. I'm talking about that problem.

WHO does the change effect?
WHAT was the actual change?
WHERE do I find the change in the product?
WHY was the change made? (It's hard to support something if you don't know why it was done.)
WHEN will the change be released?

One thing I want to stress is the importance of the WHY something was done. For customer support people to be really good at their job, they need to understand the product and how people use it. Knowing how to enable a feature is one thing. Knowing why someone would want to enable it, is a whole different thing and the difference in good customer service. Another challenge is getting support people to better test and document potential bugs before escalating them to development. Trying to fix bugs without examples is always fun... NOT. They might as well say "The sky is falling, please fix it!"

We need to over train the support staff about product changes and continually stress how they document and test potential product bugs. You also have to train the sales staff and the marketing team. Then there is updating sales materials, your website, product documentation and other items there are always out of date. Every product release causes this vicious circle of trying to educate the rest of the company about the changes.

Do we need to record a simple video explaining the changes and email it to everyone? Maybe we should  use a simple online training type app to help with this problem. Ultimately the struggle is taking the time to do the training, but it is time well spent. It may save you a lot of time answering questions and fixing bugs later. 

How do we efficiently transfer key product knowledge from developers and product owners to the rest of the company? How have you solved these issues at your company? 


Mozilla Persona to the login rescue?

Wed, 03 Oct 2012 03:36:28 GMT

Originally posted on:

A lot of websites now allow us to login or create accounts via OAuth or OpenID. We can use our Facebook, Twitter, Google, Windows Live account and others. The problem with a lot of these is we have to have allow the websites to then have access to our account and profile data that they shouldn't really have. 

Below is a Twitter authorization screen for example when signing in via Technorati. Now Technorati can follow new people, update my profile and post tweets? All I wanted to do was login to to comment on a post!


Mozilla has just released their new solution for this called Persona. First thought is oh great another solution! But they are actually providing something a little different and better. It is based on an email address and isn't linked to anything like our personal social networks or their information. Persona only exists to help with logging in to websites. No loose strings attached.

Persona is based on a new standard called BrowserID and you can read more about it here:
How BrowserID Works.  The goal is to integrate BrowserID in to the browser at a deeper level so no password entry is required at all. You can tell your web browser to just auto sign in for you. I am really hoping this takes off and will look at implementing it in current projects! I would recommend researching it and lets hope it or something like it becomes a wide spread reality in the future.

JavaScript Sucks. TypeScript Makes it Suck Less?

Tue, 02 Oct 2012 02:09:01 GMT

Originally posted on:

JavaScript Sucks. Yes, I said it. Microsoft's announcement of TypeScript got me thinking today. Is this a step in the right direction? It sounds like it fixes some of problems with JavaScript development. But is it really just duct tape and super glue for a programming model that needs to be replaced?

I have had a love hate relationship with JavaScript, like most developers who would prefer avoiding client side code. I started doing web development over 10 years ago and I have done some pretty cool stuff with JavaScript. It has came a long ways and is the universal standard these days for client side scripting in the web browser. Over the years the browsers have become much faster at processing JavaScript. Now people are even trying to use it on the server side via node. 

As an enterprise web application developer, I don't like any scripting or dynamic languages. I like code that compiles for lots of obvious reasons. JavaScript is messy to code with and lacks some modern programming features. There are compiling tools like Closure, jQuery, minify, coffee script, TypeScript and a bunch of other tools that have improved JavaScript. TypeScript looks like it will help with some of the problems like having variable types, compiling, and a better IDE to work with. We spend a lot of time trying to hack it to do things it was never really designed for. I don't think there is any point in debating in this post what the problems with JavaScript are. That isn't the point of the post and anyone who has used it has their own laundry list. (My favorite? Doing financial calculations in JavaScript is lots of fun.) The question is are we stuck with using JavaScript on the client side forever now? What alternatives do we have?

It is possible to program in Silverlight, Java or Flash and run that in the browser instead of JavaScript, but they all have their own problems and lack universal mobile support. I believe Microsoft's new TypeScript is a step forward for JavaScript, but I think we need to start planning to go a whole different direction. 10 years from now is JavaScript going to be the primary solution on the client side still? We need to start thinking about what replaces JavaScript... and I have no idea what the solution is. 


Production Access Denied! Who caused this rule anyways?

Sun, 23 Sep 2012 03:01:23 GMT

Originally posted on: of the biggest challenges for developers is getting access to production servers. In smaller dev teams of 5 or less people everyone usually has access. Then you hire developer #6, he messes something up in production... and now nobody has access. That is how it always starts. Just about every rule in life gets created this way. One person messes it up for the rest of us. Rules are then put in place to try and prevent it from happening again. Breaking the rules is in our nature. In this example it is for good cause and a necessity to support our applications and troubleshoot problems as they arise. So how do developers typically break the rules? Some create their own method to collect log files off servers so they can see them. Expensive log management programs can collect log files, but log files alone are not enough. Centralizing where important errors are logged to is common. Some lucky developers are given production server access by the IT operations team out of necessity. Wait. That's not fair to all developers and knowingly breaks the company rule!  When customers complain or the system is down, the rules go out the window. Commonly lead developers get production access because they are ultimately responsible for supporting the application and may be the only person who knows how to fix it. The problem with only giving lead developers production access is it doesn't scale from a support standpoint. Those key employees become the go to people to help solve application problems, but they also become a bottleneck. They end up spending up to half of their time every day helping resolve application defects, performance problems, or whatever the fire of the day is. This actually the last thing you want your lead developers doing. They should be working on something more strategic like major enhancements to the product. Having production access can actually be a curse if you are the guy stuck hunting down log files all day. Application defects are good tasks for junior developers. They can usually handle figuring out simple application problems. But nothing is worse than being a junior developer who can't figure out those problems and the back log of them grows and grows. Some of them require production server access to verify a deployment was done correctly, verify config settings, view log files, or maybe just restart an application. Since the junior developers don't have access, they end up bugging the developers who do have access or they track down a system admin to help. It can take hours or days to see server information that would take seconds or minutes if they had access of their own. It is very frustrating to the developer trying to solve the problem, the system admin being forced to help, and most importantly your customers who are not happy about the situation. This process is terribly inefficient. Production database access is also important for solving application problems, but presents a lot of risk if developers are given access. They could see data they shouldn't.  They could write queries on accident to update data, delete data, or merely select every record from every table and bring your database to its knees. Since most of the application we create are data driven, it can be very difficult to track down application bugs without access to the production databases.Besides it being against the rule, why don't all developers have access? Most of the time it comes down to security, change of control, lack of training, and other valid reasons. Developers have been known to tinker with different settings to try and solve a problem and in the [...]

Access Log Files

Sun, 16 Sep 2012 02:04:43 GMT

Originally posted on:

Some of the simplest things in life make all the difference. For a software developer who is trying to solve an application problem, being able to access log files, windows event viewer, and other details is priceless. But ironically enough, most developers aren't even given access to them. Developers have to escalate the issue to their manager or a system admin to retrieve the needed information. Some companies create workarounds to solve the problem or use third party solutions.

Home grown solution to access log files

Some companies roll their own solution to try and solve the problem. These solutions can be great but are not always real time, and don't account for the windows event viewer, config files, server health, and other information that is needed to fix bugs.

  • VPN or FTP access to log file folders
  • Create programs to collect log files and move them to a centralized server
  • Modify code to write log files to a centralized place

Expensive solution to access log files

Some companies buy expensive solutions like Splunk or other log management tools. But in a lot of cases that is overkill when all the developers need is the ability to just look at log files, not do analytics on them.

There has to be a better solution to access log files

Stackify recently came up with a perfect solution to the problem. Their software gives developers remote visibility to all the production servers without allowing them to remote desktop in to the machines. They can get real time access to log files, windows event viewer, config files, failed iis request logs, and other things that developers need. This allows the entire development team to be more involved in the process of solving application defects.

Check out their product to learn more

Agile Development Requires Agile Support

Mon, 10 Sep 2012 20:30:53 GMT

Originally posted on: development has become the standard methodology for application development. The days of long term planning with giant Gantt waterfall charts and detailed requirements is fading away. For years the product planning process frustrated product owners and businesses because no matter the plan, nothing ever went to plan. Agile development throws the detailed planning out the window and instead focuses on giving developers some basic requirements and pointing them in the right direction. Constant collaboration via quick iterations with the end users, product owners, and the development team helps ensure the project is done correctly.  The various agile development methodologies have helped greatly with creating products faster, but not without causing new problems. Complicated application deployments now occur weekly or monthly. Most of the products are web-based and deployed as a software service model. System performance and availability of these apps becomes mission critical. This is all much different from the old process of mailing new releases of client-server apps on CD once per quarter or year.The steady stream of new products and product enhancements puts a lot of pressure on IT operations to keep up with the software deployments and adding infrastructure capacity. The problem is most operations teams still move slowly thanks to change orders, documentation, procedures, testing and other processes. Operations can slow the process down and push back on the development team in some organizations. The DevOps movement is trying to solve some of these problems by integrating the development and operations teams more together. Rapid change introduces new problemsThe rapid product change ultimately creates some application problems along the way. Higher rates of change increase the likelihood of new application defects. Delivering applications as a software service also means that scalability of applications is critical. Development teams struggle to keep up with application defects and scalability concerns in their applications. Fixing application problems is a never ending job for agile development teams. Fixing problems before your customers do and fixing them quickly is critical. Most companies really struggle with this due to the divide between the development and operations groups. Fixing application problems typically requires querying databases, looking at log files, reviewing config files, reviewing error logs and other similar tasks. It becomes difficult to work on new features when your lead developers are working on defects from the last product version. Developers need more visibilityThe problem is most developers are not given access to see server and application information in the production environments. The operations team doesn’t trust giving all the developers the keys to the kingdom to log in to production and poke around the servers. The challenge is either give them no access, or potentially too much access. Those with access can still waste time figuring out the location of the application and how to connect to it over VPN. In addition, reproducing problems in test environments takes too much time and isn't always possible. System administrators spend a lot of time helping developers track down server information. Most companies give key developers access to all of the production resources so they can help resolve application defects. The problem is only those key people have access and they become a bottleneck. They end up spending 25-50% of their time on a daily basis trying to solve application [...]