Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am looking for honest / constructive feedback.
I hear a lot of my peers who have been using .NET for a while now, say how easily they built their GUI interfaces. On closer inspection they have used 3rd party tools such as Infragistics.
As a new .NET programmer (certified I may add), I wanted to know if anyone has actually created interfaces using nothing but what ever happens to be available by default with the framework...
I am guessing it shouldn't be too difficult to create a good, aethestic looking GUI without using 3rd party addons.
Yes We've done it (windows).
Depends on where you put the emphasis in your guess. No its not TOO difficult, but it's definitely not easy, unless your requirements are truly trivial, as opposed to apparently trivial.
All depends on what you need / want to do. My advice don't tell your boss, this will be easy, well not unless you want help getting out of the door for the last time.
For instance take a straight textbox.
They want to enter currency in it.
Multiple rounding algorithms.
Enter raw value display formatted, Currency symbol, thousand
separators.
Optional pounds or pence.
Optional blank or zero
Optional treatment of negatives.
Optional display formatting of negatives.
Alignment on decimal point.
Auto change of font on resizing.
And break none of the standard behaviours.
Trust me not simple at all. Especially if you do something Infragistics did not, and go for a good developer interface as well as the end user behaviours.
Not trying to put you off. It's challenging and rewarding, but when you have the entire application stuck behind some irritating bug in the UI, bosses lose patience real quick and you haven't got that get out of jail free card in shrugging and saying that's how X works.
NB just buying a suite won't fix all these problems, you can spend a lot of time producing a totally crap UI with them as well, just you don't have to write the code...
The answer to that is a lot of hard work. :(
Can your current suite be upgraded?
If you have the source could it be fixed, if you had the source and it's been twiddled with, are those "improvements" interfering?
Needs some hard-headed realistic analysis this. Which components are broke? How much are they used? How much of the extra behaviour in the suite do you really need.
Most important, how good is your separation of concerns in the current code, and how comprehensive both unit tests and automation tests.
Would compatibility mode sort it out?
Need to get to a point where the number of questions doesn't significantly out weigh the number of answers.
I've been where you are though it was another suite in another environment. The people looking for the cheap, quick and painless way of dealing with a mess like this were hugely disappointed, but it can be attacked in parts as long as everybody takes a heavy dose of pragmatism.
As a for instance,
Someone had bought a windows component that looked like a html link, and was heavily dependent on File associations and API calls. It was very visible and all over the place, I knocked up a much better and far less fragile one in a few days, swapped it in, a lot of perceived problems disappeared, confidence increased, and the remaining problems started to look less horrible.
Think of it like going into triage mode on bugs at the end of a struggling release.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
First, please no spamming because I am not necessarily an OOP devotee. That said, I have been a programmer on and off for almost 30 years and have created a lot of pretty cool production code systems/solutions in several industries. I've also done my share of break/fix, database development, etc. Even a bout 10 years as a web programmer, not developer, so I an not so much a newbie but someone trying to get an answer about something that frankly is eluding me.
I started as a "C" programmer int he early 1980's and "C" served me well into the early 2000s (even today most scripting and higher level languages use "C" syntactical elements).
That said, overloading seems to violate every principle of what I was taught were "good coding practices" by increasing ambiguity in the opportunity for omission of intended code to be executed for a given condition or actually running a routine you didn't expect to due to some condition falling through the cracks. Also generally seems to creates LOTS of confusion for learners.
I am not saying overloading is bad per se, I just want to better understand it's practical application to real problems other than simply a way to provide input validation or perhaps just to handle inputs from other sources that you have no control over in an API or something else that you don't necessarily know the type of (again not clear on how or why that could actually happen either) C# has a lot of parse and try catch to handle this as do most OOP languages.
In over a decade, I have yet to get a straight, non judgmental and dare I say unsnarky answer to this question. Surely there is someone who can offer a reasonable explanation of why it is used.
So I pose the question to you the stack overflow gurus, Personally, does having a method/function that is potentially callable multiple different ways with multiple exclusive code segments really a good thing, or does it just suggest lack of good planning when designing software. Again, not knocking, judging, or disparaging, I just don't get it.....please enlighten me!
I'd say std::to_string is a pretty good example of good use of overloading. Why would you want to have different functions for converting different types to std::string? You don't. You just want one - std::to_string and you want it to behave sensibly whatever type of argument you give it - and it does just that. Using overloading keeps the client code simple.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
So, before I post my question, I will add a little bit of premise to it. I have written quite some code for academic purposes, but never before was it for production or an actual client.
What I would always do is this:
private void button1_Click(object sender, EventArgs e)
{
//Do all the programming here
}
However, now when I have to build actual software for client (a small one), I find this process tedious and hard to handle as the code grows long.
I still create separate classes and do some of the work here and there, but I think it's not the correct direction.
What am I missing? How professional developers do it?
Thanks.
EDIT : This is not exactly a coding question however I still choose StackOverflow because I really want the different perspectives of the superb professionals present here. I am just an industry newbie, so I really need to start learning in the right direction.
I find this process tedious and hard to handle as the code grows long.
You are correct.
I still create separate classes and do some of the work here and there, but I think it's not the correct direction.
It is the correct direction. Programming is about abstraction. Properties, methods, handlers, classes, and so on, are all abstractions. Abstractions are useful because they present less complexity than their implementation details, and can therefore be understood and used effectively. Just as you do not learn how to drive by manipulating valves and cylinders and springs and camshafts; you learn abstractions like brakes and gear selectors.
When you learn to drive you are handed a pile of abstractions which you must learn to use. When you are programming you are both handed a pile of existing abstractions -- variables, lists, types, and so on, are all abstractions -- but you are also expected to build your own.
How do professional developers do it?
This is not a site to teach you how to program. This is a site for specific questions about actual code. Professional developers do it by spending thousands of hours learning from others and practicing their craft; go get started! Come on back when you have a specific question about actual code.
I think you are doing it right ! Indeed managing large programs is a hard job, you have to know how to modulate your code. You can create diagram representing your project so it will make the editing a lot easier.
Here is a link with some tools for Architecture and Modeling with Visual Studio
https://www.youtube.com/watch?v=ThEP7DgVAC0
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've been working for a couple of years on a small project, almost by myself, with the eventual help of some colleagues. The project is getting out of my hands, because the size of the code is growing (around 20K lines now) and the initial expectations I had for it have outgrown my own ability and time. So now I want to open source it, with the hope to attract some contributors. My motivations for going open source are these:
The project is rather academic (a library of algorithms for scientific computing), and I don't really have any economic interest in it.
The project is getting too big for me to handle it by myself, and the number of features I've planned are enough to keep a small team motivated (I think).
It needs a lot of testing, not just unit testing, but testing in the real world to see if the API is easy to use, the performance is as expected, etc.
I'm sure it has a lot of bugs, but I can only find a few, since its me alone testing it.
It needs proper documentation, because the API is getting a bit complex.
Other than that, I think that the project could benefit from a comunity in terms of deciding which features are most needed, and creating a set of guidelines for the future development.
I'm using Git, so my first thought was to publish it on Github and/or Codeplex. Besides that, what would be the steps to help to slowly grow a community of users and perhaps developers around it? Do I need a domain of my own, or should I stick to Github/Codeplex? How do I set up a platform for collaboration between developers potentially geographically separated? Should I set up a mailing list? And most important, how do I attract people to use it and collaborate with it?
The project is a .NET library for optimization and machine learning, written in C#.
There is only one piece of advice I can give here; use Github. It is common, (pretty much) everyone knows about it, it is easy to use, and the community who you are trying to attract is already on it. It has a ton of tools which you may not have even thought about, but may come in handy. It it pretty much the perfect solution for what you're looking to do, so don't overthink it.
As for attracting people to use it and contribute, if it is something that is useful and good, people will find it. I have found a ton of obscure projects with a simple google. If someone googles for something related to your project (and it is appropriate named and such) they will likely find it. There isn't really much you can do to force a demand though, just let it happen. As for contributors, people who are using it will likely contribute they're additions back. Just be sure to stay actively involved in managing it (monitoring pull requests, etc). If no one is accepting requests or managing versions, contributors will likely start to give up on your project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been programming for a few years in C# and XML. I used only the basics of those languages and have survived on the web for info like arrays and text manipulations. But when I am get interview, the interviewers ask only advanced questions - I found the answers later in the Advanced sections in the books on the subject.
Why do the interviewers ask such advanced questions? The job looks almost the same as what I was previously doing, so there's need for advanced knowledge, like what class delegate is or XPath commands.
Questions are:
What version of XSL does .NET 3.5 uses?
What XPath command to use to get value in element X?
What are class delegates in C#
Does C# allows multiple interface inheritance?
How do you access GAC in C#?
There are two reasons that I ask them.
To see a person actually say "I do not know the answer to that", as opposed to trying to BS through the question.
To see what kind of logical problem solving skills a person has.
Usually a question will be of one or the other, but not both. Both are extremely valuable in screening a perspective employee, however.
Also, the question might not actually be "advanced" for the position. It is reasonable to assume that Senior-level and/or Architects can answer questions that a Junior to Mid-level might not.
Perhaps because they are trying to find programmers who know more than the basic stuff. If they are trying to distinguish between a field of candidates, it isn't helpful to ask questions that everyone knows the answer to - how do you select among those candidates? If you're going to hire only 1 or 2 out of a pool of candidates, you need to find some harder questions that only 1 or 2 out the pool can answer.
Getting the answer wrong is what I want from an applicant in some cases.
One of the reasons I like to ask a question that I think the applicant will get wrong is to see how they adjust to the situation. How they handle getting something wrong and handle someone telling them how they should have answered etc. If they are very defensive or rude when you tell them they are incorrect then it is a good indication of how they will work on a team when many times your ideas will be challenged.
If they take the solution or recommendation and realize they can learn from it or even add to it that is usually a sign of someone what is easy to work with and willing to work 'outside of their box'. If they just make excuses and dance around trying to say why they could be right or should be right (in cases where they are clearly not) then this tell me when the same issue arises in the future this applicant is going to cause headaches.
Not so worried about the answer, more interested in how they react to the question / solution.
Another reason would be to gauge their level when hiring as well. You might be hiring for a bunch of positions but not sure where this applicant fits. Hard questions that show problem solving and attention to detail can sometimes make it easier to categorize their skill set.
I ask advanced questions for a few reasons:
Some of my questions are advanced usage of things everyone should know (not a trivia question) -- I want to see you reason through the answer using knowledge you have, but in a way that isn't common.
I want to see what happens when you don't know something -- do you give up?
I want to hire people that are serious about what they do. People that really care about the technologies they use tend to want to know the advanced stuff.
I want to see if there are gaps where you just don't know that an entire area of knowledge even exists. For example, in your XPath example -- I might be ok with: "I believe that XPath could be used to help solve this, but I don't know it well enough to write it out here" -- then I would show them a little XPath and see if they could apply it. If you don't even know that XPath exists, google isn't going to help you.
Likely they're just getting a gauge of where you are. They probably got stuck on this problem themselves and perhaps wanted to see if you could think of an answer on your feet.
I've experienced the same types of questions, and considering when I program I use excessive resources, this type of thing usually throws me off. Their loss.
Because competency as a programmer involves both depth and breadth of knowledge.
The interviewer is trying to devine your level of knowledge, and he is copping out by "borrowing" a question from the last chapter of that book.
Really, this is sloppy work on his part, relying on one question to guage your expertise level. You may have low programming skills, but recently come across the buzz-word, and are able to ace the interview.
I did get burned once in interviewing a candidate who professed high levels of C expertise. It turned out that he was reading "C for Dummies" and managed to BS through the interview process. I admit that I wasn't concentrating on his programming skills, but was looking for other aspects, which he also managed to BS through. Turns out his whole resume was a pack of lies.
Nowadays, I make sure the candidate has working knowlege of variable scope, persistance, pointer arithmetic, basic algorithms, structured programming, object-oriented programming, polymorphism, multitasking and inter-process communication. I will quiz him on his debugging skills, and zero in on details such as race-conditions, heisenbugs and security vulnerabilities.
Depending on the job, I will ask about experience in the target language - such as key=>value maps (arrays) in PHP, Swing programming in Java, event handling in C#, tables vs CSS in html -- you get the picture.
If the candidate passes the first part of the interview (I usually know within about 5 minutes), I will then give him a binder and send him into the coffee room (nice couch and table there) to prepare for 20 minutes for a code review on a selected module.
That's when I send in the troops - employees are instructed to use the coffee room normally, introduce themselves and make conversation for about a minute.
What I'm looking for is the ability to concentrate on a task (blatant ADHD), the ability to work under pressure, and interpersonal dynamics.
When the candidate returns, I have him act as main presenter and start our normal code review process. The first thing I look for is if he read the page titled "Code Review Process". I'm not looking for him to complete the review - about 10 minutes is enough. As a matter of fact, the fewer main lines processed, the better - within reason.
I haven't been burned by a new hire for a long time now.
Your username suggests you like coding (duh), but your question suggests you don't. If you really liked coding, then you should love to learn about it. Those questions that you listed are not that advanced.
Even if those questions were advanced, the interviewer is trying to gauge how much knowledge you have in the area that you say you have knowledge in. They are also trying to gauge how well you would fit into their group.
P.S. Not to be mean, but if you program using XML and don't know what XPath is, then you are a little far behind.
They probably want to see if you really know what you're talking about or if you're a novice programmer who gets along on the web using only what he has picked up through trial and error...
1.What version of XSL does .NET 3.5 uses?
Because they can't tell important things from non-important ones. Bad sign.
2.What XPath command to use to get value in element X?
Because they want to see if you know XPath. This can be either because they use it extensively and you need it to get they job done or because they think XPath knowledge == skill.
3.What are class delegates in C#
(I've never heard the term "class delegate" and a google search shows no definition, so I assume you mean just "delegate").
Delegates can hardly be considered an advanced topic.
4.Does C# allows multiple interface inheritance?
If they really asked about "interface implementation", it's part of the most basic concept so it's a valid question (although too simple to really mean anything). If they really asked about "interface inheritance", it's more of trivia, but I would still say acceptable. Bonus point for them if they asked what "interface inheritance" really means.
5.How do you access GAC in C#?
This is the kind of thing every team MUST have one person who knows. I'd say it's also a indication of seniority (which BTW, I don't care much about) since nobody reads about these things, the only way to find out is to be forced to solve a real-world problem.
I ask advanced questions to try see how people work through the problem. I like to ask questions that I don't know off the top of my head for that reason.
I want someone who is a critical thinker rather than just an academic who can recite text books to me.
They want to find someone with practical experience that extends beyond what is taught in beginner courses. When my company interviews candidates, we often find that most of the applicants cannot solve what we would consider to be very basic programming problems simply because they don't know the API or don't understand when to use various basic data structures.
If you want to impress an interviewer, work on your own programming projects outside of class. Learn a good chunk of the language API, and start learning about third-party libraries that can greatly simplify your work.
Another reason is to gauge your response to a question they really don't expect you to know the answer to. Problem solving skills are essential, so asking you questions you already know the answer to is not going to address that, is it?
There are even instances of companies asking odd, non-programming related questions just to see how you think your way through a problem. There is the classic "Why are manhole covers round" question, reportedly asked at Microsoft interviews.
More Microsoft interview questions
I'm not meaning to offend you but maybe your understanding of the job is not deep enough and it in fact requires knowledge of advanced techniques.
Also, you can do a lot of things with basic methods but advanced methods might the better way to implement regarding complexity, time to implement or maintainability.
There are many possible reasons. They may:
actually use those techniques (delegates and XPath aren't particularly rare or obscure)
have a large pool of candidates and want to try to find the more knowlegable ones
want to see where the limits of your knowlege are, so they ask question up to the point where you start to be unable to answer well
want to see how you might approach areas that are unfamiliar to you - to see how you might adapt to new stuff
want to show off their own knowlege (probably not a legitimate reason, but it certainly happens)
I've heard these really aren't in use anymore, or at least not nearly as much as they used to be, but you might be interested in this. I picked up a pretty cool short book a few days ago that has to deal with the "Microsoft style" logic interview questions that are sometimes asked. I'm a few chapters in and it gives a neat little history of the tech field's interview style and has a ton of logic problems, complete with answers in the back.
It's called "How Would You Move Mount Fuji" and it's on amazon for pretty cheap.
http://www.amazon.com/gp/offer-listing/0316919160/ref=dp_olp_used?ie=UTF8&condition=used
I've just completed a round of interviews, where I use a three or four stock 'simple' C# code fragments that the interviewee will look through and attempt to explain what the expected result will be. In each case the code sample is no more than ten lines of clearly-formatted code that utilises basic C# skills (inheritance, generics, anonymous delegates); also in each case there will be a 'gotcha' - but like others have stated, I don't put these in to be spiteful, they're there because I want to see how the candidate reacts when confronted with something that doesn't work as expected.
We had a candidate recently that had sailed through the first part of his interview; impressive CV, was apparently the Lead Developer of a team of 10 and had been developing code in C# since 1.0; yet apparently had no idea what "Console.WriteLine()" did (nor could he even hazard a guess), nor could he even begin to cope with the tiny anonymous delegate example.
Another candidate was self-effacing, and didn't know how to grade herself as a developer - she'd had less experience than the former candidate yet she sailed through the code samples, fell for a couple of the 'gotchas' but asked the right questions to get the correct conclusions and genuinely learnt from the experience. Needless to say, she was hired.
If you're claiming domain-specific knowledge (like XML) you should expect to be asked specific (and sometimes hard) questions about that domain; if I'm interviewing a senior ASP.NET developer and they've got no idea about HttpModules or HttpHandlers (like some recent interviewees) then alarm bells start to ring.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a working prototype for a killer app implemented in C# for Windows Mobile. It needs to be packaged into a commodity and efficiently sold. Possibly also converted to a web-centric platform.
Now I'd like to assemble a community of seasoned, possibly semi-retired IT professionals. They should be willing to work for fun and free, with an eye to future profits. I realize not many people have the option to risk their time on something like this, but - hey - on a global scale there should be more than one.
I've googled variants of the above, but no dice. And I don't really see SourceForge et al as venues for recruiting, but more as the place where you MIGHT put your code base when the project is under way. I'm not well versed in Open Source, and I'm not sure I want to "open the kimono" on the source until there's been some modicum of vetting process (goes both ways, of course).
So, rephrasing the question: what is the best site for recruiting people to a project like this?
Honestly, you may want to go with a social networking site like LinkedIn.
Your best bet on a risky project like this is to work with people you already know, and who already know you. If there are some bonds of trust in place already, you'll have a vastly greater chance of success, and a lot fewer unexpected personnel problems. Extending this to a 2nd degree contact (someone who knows someone you know) is a good next step.
Only if you really have no other options should you start pulling in people you've got no prior connection with, unless a) you're famous, or b) you want to start paying them and go through a more intense vetting (hiring) process.
Posting here probably helps, too :)
I wouldn't work for free for anyone unless they were already a close friend. Too many ways to get screwed.
To write a commercial application asking others to contribute without getting paid - even if you would give them a profit later on - to me that looks difficult.
I think you'd be better off to release a first version, perhaps with some limits, of your software for instance on XDA-developers. If it gets popular, you will have many free beta-testers out there and probably a lot of "skinners" who would probably contribute free-of-charge for the grafical user-interface. At this stage, you will probably get to know other developers at XDA who could help out with some stuff. In the beginning you could ask for donations and if you get some, you know that you have a software that people would be prepared to pay for. Then later on you could release a "Professional version" with more features that you could charge for.
just my 2 cents
I'm not well versed in Open Source, and I'm not sure I want to "open the kimono" on the source until there's been some modicum of vetting process (goes both ways, of course).
The best open source projects tend to be the ones that are developed with the mindset that nobody else will ever join your project. Start out with something simple that you can code yourself and then start putting the word out once you have a decent prototype (and treat every user as a potential volunteer). You may also consider recruiting anybody already in your network (friends, coworkers, etc) as they'd theoretically be more apt to join such a project.
It will be pretty difficult for you to get someone to commit to a project with a promising but early codebase. It will be even more difficult for you to recruit people with no codebase and no money.
I'm speaking mostly about the open source world, but I'd imagine that this would apply to a small shareware app as well. With that said, I'd recommend giving producing open source software a read if you want to learn more about the open source process.
To expand on ceejayoz's answer:
Even if you're friends, it's a heckuva way to get screwed. Things get said, promised, and discussed over beer with friends. Later, when there's something to lose (codebase, cash, clients, options) suddenly people have different recollections about who was going to get what.
Even if it's your bestest buddy, write down the details of your agreement. The more complicated the agreement, the more necessary it is for each of you to have a lawyer look at it.
The potential problems multiply with strangers. One of my bosses was also general counsel and she once said "If you don't trust the person, it's impossible to write a contract that will ensure their compliance".
It sounds like you're a developer and that's what you want to continue doing. If that's the case, I would recommend a joint venture.
That is, partner with someone who has the marketing skills that you need to get your product out to a wide range of people.
As far as places to look for those types of people, I would start at jvnotifypro.com and branch out from there looking for other sites similar to it. I believe at that site they have a few posts that mention some of those other sites.
Depending on your marketing budget, you could also go the route of paying people to install your program, paying for leads, etc. There's a lot of ways to market a program and to get the best coverage you really have to think outside the box.
Oh, you can also submit software to the sites that support PAD - I think there's an app called AutoSubmitPro that will do this for you. That's a great way to get your software out there a bit so that people know about it.
I agree with Jason. The way I did it in the past was through my existing network augmenting my skill set. Hopefully, it takes off from there!
From my experience the best thing to do is come up with a sales pitch for the other people you want to join the project you will have to sell the idea to them the same way you would sell it to a customer, people have to believe in something if they are going to work for free.
Additionally if you expect a professional to work for free you are going to have to give them a stake in the company...how big a stake all depends on viability of the project and your negotiating skills.