I am new in memchached concept. I search everywhere but i couldn't find anything how to implement in ASP.net 4.0. Can anyone tell me about the right concept.
I successfully installed memchached Server in services.msc
Now what to do after this step.
can any one have good example in Asp.net. If yes, Please provide me.
OR Please tell me step by step code.
I also read these article
http://rsuharta.wordpress.com/2011/04/27/memcached-provider-in-the-net-web-application/
But didn't understand anything. Please provide me best solution
Thanks.
Here is a CodeProject article walking you through using memcached in an ASP.NET application.
However, let me first say that it's awful likely that if you don't already understand the concept of a framework like memcached you don't need it.
Let me try and make this as clear as possible so you can make the right decision. For some reason, as of late, data caching has become the new "golden hammer" and all kinds of frameworks have popped up. But the problem is that most developers don't understand the real driving forces behind implementing data caching and they don't understand that it's really not a trivial matter. I'm going to give you the same example I gave someone else just yesterday on SO, but a paraphrased version.
Imagine if you will an application stack (i.e. more than one application) that accesses a shared set of data at a rate of more than, and I'm going to give you the real number, 40M+ transactions per day. Now, when I use the term transaction here I really mean read or write. Which only complicates things BTW because now I have to optimize for both.
Alright, so now we have a set of applications accessing this shared data at a ridiculous rate per day - how do we ensure reasonable response times for both read and write? Data caching. But, if you're not sitting in that boat you probably don't need data caching and need to spend your time learning other things that are more relevant to what you're doing.
Related
There was a similar-ish question here on SO https://stackoverflow.com/questions/9475795/how-do-you-share-code-across-teams-working-on-very-different-projects but mine is about writing documentation.
Scenario:
Let's say my team is working on a software project, a Fany-WordPad like application which has a feature called Fancy-Word-Art ( just like MS Office's word Art). Now I wrote the code for the main window( using WPF in .Net, or using Window Builder in Java, doesn't matter which tool/language).
Now if my colleague Mr Spongebob is writing the Word-Art part, how would I tell him what functions to call / Api to use to draw on my window? i.e. How do I let Mr SpongeBob know that he needs to call GetWindow() method to get a reference to the drawing surface, the parameters he needs to pass along , and so on?
I hope I am being clear here. Is this the procedure?
Step 1 : Use your company wiki site to understand your colleague's written code
Step 2 : Write the GetWindow() method so that it works well with the rest of the project
Step 2 : Now put a wiki on your intranet with the method parameters/ data type requirement for your GetWindow() method or use Doxygen/ Confluence as suggested below
Step 3 : Now its your colleague Mr Spongebob's headache how to find how to draw his word-art on my window.
This just doesnt sound right .. With tons of functions, Spongebob's life will be hard, just as mine. Both of us rummaging through documentation to find the right functions to do our job. What if then I change GetWindow() to GetWindow(string title).. Now how do I literally tell the poor spongebob he needs to redo his code.
Am I missing something here? Please share your experience, how do you tackle this problem in a real world software house environment? If your fellow developer is on the next table , do you actually show them how to implement a certain method as they get stuck, or how do you deal with this situation?
thank you
Thanks
A good question. Of course i do not have the universal solution. Code documentation in msdn/sun style is a good base. But for concepts, architecture and so one you need more than this. In some projects we use wikis for that. For customer requests, we have a kind of ticket-system where we also store some (no-code) information to solution. All in all there is no central place for all the documentaion stuff.
Edit: Your code in self is often the best documentation, following clean code guidelines or something else is a real best practice :-)
Wikis are a cracking idea (good suggestion #Micha!). I used to use one in a previous company for a large engineering software/hardware project. It obviously spanned hardware and software guys and so it was a great way to share info across all teams. It's really useful if it's a long term project too - you can keep track of changes to functionality/API as things inevitably morph over time.
We used a paid service - Confluence if I remember rightly; but there are free wiki hosting sites too e.g. wikihost (just a quick google search, I can't vouch for them).
On another note though - have you thought about self documenting code at all? For example "Doxygen" or similar? Takes a lot of pain out of documenting every single function and also sets up a decent framework that can be padded out with more info where necessary. It also creates a nice UI for stepping through all the functions /class etc.
Edit: I've actually just started using Google Sites (sites.google.com) to create a wiki for a dev team I'm not working with. It's free (as in 'beer') and seems pretty good so far, although it does lack auto code formatting.
IMO you need both API documentation and plenty of examples.
You might get some mileage out of documenting your code of course, but if you're truly writing a system properly, your clients will never see your code. (That goes for clients in the calling sense, not necessarily in the "paying for your services" sense).
That's a fundamental of good practice and SOA, so you should really discard the "self documenting code" approach.
An alphabetic list of functions/methods/properties/whatever has value once the client has "got it" but until then, it's not immediately useful.
So that leaves you with having to showcase your creation. Give a bunch of immediately useful examples that demonstrate the kind of thing you envisaged. Make sure you have a simple example that demonstrates every function in its basic form with minimal interaction with the rest of the system (too many required interactions and you've probably not got a clean system anyway).
Once you have that, put it on a Wiki and encourage your users to enhance it. Consider using something interactive like a Stack-Overflow-like platform. MSDN is a good model but their examples often suck and can lack context. You might have the luxury of having more tight and specific uses than, say, the entire .NET framework. Early response to questions and updates to your examples/documentation will ensure your message gets across in the vital early days. This will help your documentation burden tail off quickly by looking after your clients and giving them useful, practical help.
Hope that helps.
In my projects I use a short description in my class files at the top, like:
//======
//
// modul: fileRunner.cs
// ...
// what: for playing audio/video
// depends on: consoleOutput.cs (Form)
//
//=======
#region HowToUse
//=======
//
// HowToUse
//
// 1. create instance of fileRunner:
// fileRunner p = new fileRunner();
// 2. run console program [progPath] with arguments [cmdsString]
// string output = p.RunExternalExe(progPath, cmdsString);
// 3. handle [output]
// if (output == "anyError"){do something;}
//
// [OUTPUT]
// "0" : process ended w/o errors
// "C" : canceled by user
// else: output is the string of the StdError, the called program submitted + StdOut after "Std output:"
//
// IMPORTANT
// Mention, this file depends on consoleOutput.cs to parse the output for gui.
// It doesn't support input ways, because the way ffmpeg is outputting doesn't allow it, it's not active
//=======
#endregion
For other classes I just named the public functions, that are self-describing.
An other option is to write on the top that they should look an the comment in the code and on the top of the public functions I use similar explanations:
#region convert an audio or video file from a drop
// FUNCTION: convertTo
// DOES: converting a file from a drop
// does not delete the original
// INPUT1: [path] as string,
// path to the destination file
// INPUT2: [e] as System.Windows.Forms.DragEventArgs,
// the args, the drop-object submits
// path of source file is in here
// OUTPUT: isConverted as bool,
// true if not (canceled or error raised)
public bool convertTo(string pWorkingFile, DragEventArgs e)
{
...
}
#endregion
If something changes you can mention it at the top too.
I think with SCM software it's a good option to mention the most important w/o wasting too much time on documentation.
as Stupid as it sounds, I would write him (Spongebob) a mail, or just tell him what he will need. If you already know who will need something in the near future, it is great if you can inform those peope before they strat to search and get headaches. Not everything in a project needs a technical Solution very often a human to human is much better.
Your documentation can also be in a wiki and then you can simply send Spongebob a link.
To reduce the pain involved in changing specifications over a large api, I'd suggest you follow the msdn/javadoc convention as mentioned earlier and also advice your team mate to use a modern IDE with autocompletion/autosuggest feature. Most of the common editors that provide auto suggestion also display documentation for the method/member to be used.
If you are seeking agile here, then docs and wikis are slight overkill; my 2 cents.
Why don't you just put your work in one git/svn project instead of working on the project parts independently? Then when you change a core function, you will see what it breaks and be responsible for fixing the methods that call it before committing your changes.
I am not a big fan of documenting extensively during development. It slows you down too much and you will have to redo it over and over again. Just create descriptive method names and be generous with you in-code comments.
For starters:
To help the situation between spongebob and yourself working together you will need some sort of Code Asset Management software (GIT, TFS, etc).
What if then I change GetWindow() to GetWindow(string title).. Now how do I literally tell the poor spongebob he needs to redo his code.
You should always start your day coding by "GET LATEST", meaning download code from the repository. If spongebob does this he will immediately see that he now needs to pass in string title as his code will stop compiling. It would be preferable that you literally tell spongebob that you have changed your code and he now needs to pass in a value, but if you are both checking in code every night and getting latest when you start coding for the day you should be both informed.
As far as the use of a WIKI or if you use Sharepoint doesnt matter. I would say to make it a little more efficient why not do this:
In your document repository (Wiki/Sharepoint) call the files by the page name so one is WordArt, the other is MainDocument, maybe one is PrintDocument (assuming these are different pages) and in the code you can simply put:
For more information on this visit the ___site at :http://yourrespositoryname.com/nameofprocedure
I've got an ASP.NET web application, that is essentially our intranet site. I made a lot of progress on the administration office's employee management pages. It ties into an SQL server database, and I'm using a three layered design (Objects, Logic, DataAccess). It was all reviewed and all of it was accepted, except! for the part that manages vacations and vacation histories.
My question, before I go into details is, how does one efficiently "untangle" code that is no longer necessary?
For example: previously I was treating each VacationDay as it's own entity with it's own history. Such that I could track the history of an individual day. To help in tracking, I have an enum called VacationDayAction, which includes options such as .Submitted, .RequestDenied, .CancellationRequested, and so on. This was in an attempt to provide meticulous detail for each day. It was then determined that we no longer need that. We do, however, still need VacationDays and all the basic functions of that (saving days, getting days, etc.), but now we no longer need any of the "history" related classes.
My problem is, when I right click a class that I no longer need in VS and go to "Show All References," I get a ton of results scattered across several pages. I need to get rid of all of them, without breaking the rest of the application. Is there not some kind of "smart" technique or method for easily untangling parts that are no longer necessary? This is particularly difficult because 90% of what I did was just fine, and needs to stay like it is. Yet scattered in that 90% is 10% of stuff that is no longer needed. I can't just go storming through with the delete key either, because with the removal of each reference, I need to be sure that any dependencies on that reference are also fixed in a way that they don't call stuff that isn't there anymore. And I still need the application is a compilable state, so that I can test along the way that the rest of the application didn't fall apart as a result of some deletion.
To give you an idea of my low level of experience, I started two years ago with having never used C#, ASP.Net, or Visual Studio. It blew my mind when, way after starting and as I was learning, someone taught me that I could use breakpoints. And then it really really blew my mind when I learned about multi-layered design. I'm wondering if there is not some technique or trick or feature that can help in scenarios like this, where you have to "untangle" and throw away unnecessary stuff.
This is not a simple question. In fact, I would say this is one of the major challenges for any systems developer; how to handle and get rid of old code which is not in use. There is lots of literature on this, and few really excellent answers. A good book may be "Working effectively with legacy code" by Michael Feathers, which deals with many related problems. It is no light read though, and will probably take some time to get through, but it will likely help you become a better coder, and better at these kinds of tasks in particular.
Maybe you can have a look at the Resharper tool? ( http://www.jetbrains.com/resharper/ ) It is a productivity tool which among other things shows "dead" code (unused code) in grey, and lets you remove it. It will also help you remove unused references from each class (again, they will be grayed out and let you remove them automatically).
Drawing diagrams where each major piece of code /component is a box with a line linking it to any related component might help you get a better overview; try to draw a hierarchy showing how different parts of the code are related and dependent.
The bottom line as far as I know, is that you just have to muddle through it, commenting out code a little at a time, then recompiling and testing it. If it still works, fine, now you can remove the commented out code completely. This would be easier if you had unit-tests covering your code, but I take it as a given that you don't, as is unfortunately often the case.
I'm giving a demo and instroduction of Visual Studio, C# and WPF to C++ on Linux developers that will be soon coding in C#. My plan is to go over a demo application that explains some basics in C#/WPF and an overview of some of the VS options.
Does anyone have any suggestions on conducting the demo?
Any good websites that can help with overviews?
Suggestions:
Keep the mood light and easy. They are probably already in bad mood after being told to throw away a good part of their skills and learn a completely different way in order to keep their job.
I really hope you are also a c++/linux developer. You'll need to relate to them somehow. If not, consider letting someone else give this intro. If they start complaining in the demo you'll have to know how to bring them back inline.
Make sure your demo shows something of real value to them. For example, "I know you guys solve problem X this way, but with WPF/C# that problem is so much easier because..."
The whole thing better be relevant to the fundamental reason why they are being forced to switch. Cover this, in detail. Make sure you answer their questions completely. Be prepared to have your demo derailed by questions. This could be a Good Thing(TM) as it would hopefully show real engagment.. as long as you keep it positive.
Make sure that you have ZERO flaws in your presentation. Any will be ripped apart, made to appear bigger than it is, and subsequently used as a reason why they shouldn't switch.
Under no circumstance should you argue with any of them. See suggestion #1.
Consider enlisting one of "them" to help put the demo together. Let that person guide some of the covered topics. This goes a long way towards good will; which you'll need in spades.
I'm making a big assumption that they weren't the ones who drove the decision to switch. Given the target, it's probably a safe assumption but feel free to correct me if I'm wrong.
Hello people from StackOverflow!
I come to you with yet another question. :)
As stated in some of my previous questions, I'm interested in creating a website that handles jobs and company openings for people to browse. I intend to have a way for people to upload CV's, apply to a position, and have companies post jobs as well.
Since I've never done a project of this scope before, I fear that I may be neglecting certain things that are a must for a web-targeted application.
I realize that is a very broad question, perhaps too broad to even answer. However, I'd really like someone to provide just a little input on this. :)
What things do I need to have in mind when I create a website of this type?
I'm going to be using ASP.Net and C#.
Edit: Just to clarify, the website is going to be local to a country in eastern europe.
Taking on careers.stackoverflow then? :)
One of the biggest things, is not even a technical thing to be thinking about - how are you going to pull in enough users to make the site take off?
It's a bit of a chicken and egg situation - if you don't have recruiters on the site, noone's CV will get viewed. If you don't have CVs listed, recruiters won't use the site. So first and foremost, you need to be thinking about how you will build up a community.
the site must have a good, easy to use, user experience. Make it easy for everyone to achieve what they want.
what makes your site stand out from others? why should people use yours instead of another one?
You could start with the free "Job Site Starter Kit":
http://www.asp.net/downloads/starter-kits/job/
* Enables job seekers to post resumes
* Enables job seekers to search for job postings
* Enables employers to enter profile of their company
* Enables employers to post one or more job postings
First you need a community. It doesn't really matter which one, but it would help if you were also a member of this community. Let's take Underwater Basket Weavers. Then find a problem that this community has or something this community needs to share. Almost invariably it involves information exchange but in some cases it may actually be service based. Then focus your efforts on solving or supplementing that issue. For our Underwater Basket Weavers, we may have a need to share techniques on how to weave specific materials, where to get materials. How could they share this information and how could you make it interesting to them?
Know your audience. Learn their issues. Apply yourself to filling that void.
I am having a problem with one of my team members output. He seems to be always 'busy' yet I am unable to see exactly what code he has done and he seems be delivering very little and it seems to take a long time to do so. I'd like to investigate further using TFS and was wondering if there is any functionality in TFS that shows what has been written by an individual or similar?
Just to clarify I am NOT spying I am trying to resolve situation. This is only a starting point. I un derstand that quantity of code does not equate to best programmer
thanks for any answers
Your best programmer may in fact write less code than your worst programmer, in fact really good programmers often write less code. Be careful about using this information to evaluate performance. Since you are using TFS, I assume you are also using the work item tracking. That is really a better way to evaluate performance than using lines of code. See which checkins cause the most problems, which fix the most defects, and how many rounds it takes for something to be truly fixed.
For me the simplest thing is to set up email alerts for checkins. You get the checkin comment, some work item info assuming they are associating/resolving on checkin, and list of changed files, as they happen. Lets you see what part of the code that dev is in and after a while you get a sense when "it's quiet. Too quiet" because someone isn't checking in. It doesn't take the place of forensics of what he did all month, but it keeps me feeling connected. It also gives me intuitive feelings like "he's in the reports, so I'll be able to show those to the user earlier in the cycle" or "jeez, he's doing all the stupid typos in error messages and other no-thinking things, and not tackling his real hard stuff" or even "he's doing his pri 2 stuff while he has a large pile of pri 1". All of these enable a 30 second hallway conversation to deliver a course correction as close in time to the problem as possible.
See the following blog post I put together a while ago:
Getting Started with the TFS Data Warehouse
This one talks you through getting code churn for each area of your codebase, but it would be easy to add team members into that as well to get a breakdown by team member who did the check-in.
But I agree with your question - this is not a good way to check on the productivity of your colleague. Instead I would talk with them to raise your concerns.
While I am away from TFS right now, you can view a list of checkins by user in Team Explorer, and in each of these you can see the files which have been changed and look at the diffs for each.
You can get this from the TFS Cube, if you have it set up. There are a large number of dimensions within Code Churn. Some of this is also available in the TfsWarehouse database as well.
If you do have the cube set up, just point Excel at it and have some fun playing around. Keep in mind, though, that the numbers can point you in the wrong direction. Use discretion.