Develop Reference

How to get started with developing software? [closed]

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 5 years ago.
Improve this question
I love programming languages and trying to think of logical solutions to problems. A lot I have been reading on C# and the underworkings of WPF. (Also Python and PyQt) In all my college courses in programming, I learn absolutely nothing (What a variable is, what an array is, NOT what stack and heap are, NOT what CLR/JVM actually does) I feel I have a very good grasp on the basics and a decent grasp on the more substantial topics.
I have been trying to make my own C#/WPF app that is governed by input sensors and output relays for home/shop automation.
I am having trouble to just do certain things. For example. make a user control to be used by a central control that also controls another user control while having a database layer.
I would really like to learn how to structure logically programs and what best design is (for example, I hate having a program filled with if/else statements). The problem is, the books I find only have basic examples that don't really deepen my overall undestanding of how all the pieces need to work together.

How do I start to do things?
You find an open-source (or at least "source available at no cost" -- not quite the same thing, but the difference should only matter if you plan to redistribute your results) project that does "something like" (maybe "vaguely" like;-) what you're trying to do, and is coded in a language that you know or want to learn.
You duplicate the source tree for that project to your machine and put the duplicate under a version control system (svn, hg, git, bazaar -- whatever -- there's a bazillion good, free ones) quite independendently from any VCS it might have been in originally -- the point is being able to save your edits all the time, and revert them easily if and when you make mistakes.
Then you start hacking, looking things up in docs and forums, asking on SO, etc, as needed;-).

There is no "one shoe fits all" solution in programming world. But i do recommend you a book. Hope you like it.
Head First Design Patterns
(O'Reilly)

Honestly... truly... the best answer? Do stuff.
I learned a lot in school. Tons. But as you said, there is a level that schools don't touch. I've got a deeper understanding in my 2 months of programming/data analyst than I got in 2 years getting my AA in programming.
Realize one thing: School is there to teach you a wide range of things - to a minimum level. You won't become an expert from school alone (There are exceptions... as with any rule).
How have I actually started to understand stuff? Programming. Boss gave me a program task and I ran with it.
Personally, I've really liked Apress books. C# 2008 Illustrated (or the soon to be released 2010) has proved invaluable to me. I actually read 95% of the book, double checked examples... and most importantly... put them into practice in my horrible first programming task. I've re-factored at-least 5 times already, and already am seeing things that will make me do it again.
I don't know if you have a job... or a hobby... an open source program you'd like to help with... or a task you'd like to automate. Pick something, learn it inside out, then program it.
Personally, again... I'd say joining an already running open-source project is too much. I tried a few times and it was too much for me. To many things I didn't understand. I plan to try again once I get a little better, but I don't plan on hanging out on NBA courts when I can barely dribble the ball myself... if ya know what I mean.

How do I start to do things?
Find a problem that needs solving and writing a program to do it. It doesn't have to pretty or efficient. The program just needs to work. As you work with the program you'll begin to learn better techniques for accomplishing the task you set for yourself. Google and SO will be your friends and help you learn those better techniques.
As other have said, jumping straight into controlling hardware with C# may not be a simple task for your first program.
Good luck.

Read Martin Fowler's book Refactoring: Improving the Design of Existing Code.
Martin Fowler gives you the building blocks to think about high level design decisions by introducing you to all the low level decisions you may or may not be aware that you are making. He also gives a good introductions to the concept of code smells.
Look at design principles like DRY Do Not Repeat Yourself, KISS Keep It Simple Stupid, and keep it consistent(Pet Peeve).
More design principles here
Design Principles.
Practice these principles as often as possible especially in your course work and outside projects..
Get involved in open source
Hard to do but probably will help you the most especially when combined with the first two.
Personal Experience feel free to skip.
After three years of tough undergrad I realized I could solve some really complex proofs but I didn't know how to write anything but spaghetti code. The longest projects I had were 5 months long which was enough time for it really to catch up with me. I was usally very productive for the first 2-3 months but was crawling along from the code debt by month 4. At this point I had the same realization you did.
Everyone says the best way to learn was to practice but I didn't know how to practice.
I realized that the problem with thinking about design was I couldn't move one design into another. A professor mentioned Martin Fowler's book Refactoring: Improving the Design of Existing Code and that has made all the difference.

Planning a programming project by example (C# or C++)

I am in the last year of undergraduate degree and i am stumped by the lack of example in c++ and c# large project in my university. All the mini project and assignment are based on text based database, which is so inefficient, and console display and command, which is frustrating.
I want to develop a complete prototype of corporate software which deals in Inventory, Sales, Marketing, etc. Everything you would usually find in SAP. I am grateful if any of you could direct me to a books or article or sample program.
Some of the question are :
How to plan for this kind of programming? should i use the concept of 1 object(such as inventory) have its own process and program and have an integrator sit for all the program, or should i integrate it in 1 big program?
How to build and address a database? i have little bit knowledge in database and i know SQL but i never address database in a program before. Database are table, and how do you suppose to represent a table in a OOP way?
For development type, which is better PHP and C++ or C# and ASP.NET? I am planning to use Web Interface to set form and information, but using a background program to handle the compute. .NET is very much integrated and coding should be much faster, but i really wonder about performance if compared to PHP and C++ package
thank you for the info

This may not answer your question directly, but I thought this might help you get started in some way. So here it goes: I would say, "think through the process". This means, think through the software development process:
Gather requirements
Identify and define the problem.
Get as much information/facts as you can. (turn on green light, think about everything that you want to go into your software)
Come up with a baseline (turn on red lights, what you really want? the minimum functionality your software "must have" - cant live without)
Analyze
Know what you don’t know, what are the missing facts?
Evaluate your information or lack of it/reliability of information source.
Infer facts that you don’t know.
Form an assumption, opinion, or possible solutions.
Consider alternatives and implications of each solution.
Form an action plan.
Identify technology pros/cons.
Decide technology
Comeup with a functional specs.
Research
Dig into stuff that you would want to know (Best database, ORM, design practices, code samples - gather everything, read about inventory systems that are already there)
Design
Develop
Test
Fix
Prepare deployment plan
Release the product
Gather user feedback
Analyze user feedback
Plan for items in next release.
Repeat steps
And Enjoy!

Before I start this is a shallow answer to a deep question.
1) It looks like you have a reasonable grasp of the major components of your target application. As a .net developer I'd build assemblies that matched broad areas of functionality (not sure what the equivalent is in PHP) and then you can use those assemblies together as a single large app, or seperately as required. It's unlikely you'll get it right first time, so build it how it feels right, and then do some ruthless refactoring to make it better once you've got a handled on the problem.
2) This whole area is covered by Object Relational Mapping - ORM, NHibernate is the best of the bunch in the .Net world. BTW if you learn that you'll be way ahead of the game come graduation/work time. Raw sql is so last decade. I guess you know that Sql Server Express is a free download?
3) For development go with the languages/environment you feel most comfortable in. My preference is .net, and the integrated coding is much faster. Performance is definitely good enough, especially as this is learning project - SO runs on .Net and that supports a gazillion users pretty well.
Enjoy

I don't have any good recommendations for SAP-like projects in particular, but in general the best examples to use for things like this are well-established open-source projects. Anything else is going to be a "toy" example in one way or the other, and will be simplified and cleaned up. It's the "cleaned up" that makes it most unrealistic -- one of the really key things that makes real-world large software projects different from university examples is that the real world is messy, and real-world requirements are messy, and collaboration between lots of people with not quite the same priorities is messy, and real-world software projects have to adapt to and thrive in this messiness.
In answer to your specific questions, though:
1.) Do things in a modular way. This means you have something you can test and work with as soon as you get the first module done. That's especially important when you're learning, because (a) you probably won't have time to actually finish the whole thing, (b) you'll learn a lot from writing the first bit that you'll want to apply in future bits and then you'll probably want to rewrite the first bit, and (c) you'll learn even more from using the first bit.
2.) There are many views on this, and many online articles and books. I can't answer that in an answer here (except to note that in some cases trying to represent it in an OOP way is the wrong programming paradigm -- be careful about overconstraining the answer by the question you ask!); the right answer is to find things to read and spend some days reading them.
3.) You do not care about that sort of performance issue here. Successful programs have been written in both forms. You care about what will teach you the most, and what you are comfortable working with. Either one should be fine. You'll probably find more open-source pieces to look at with PHP and C++.

Your question pretty much covers the whole gamut of planning for a project; a whole thesis might be written (+:
Keep in mind what your team and your teaching-staff want out of the project.
1) Modular is my choice. It'll force you to address the application one module at a time and keep you focussed, but that is subject to
The familiarity of your team with the preferred/recommended language for this project.
Time in hand
Remember that modular means you will necessarily have to provide for module integration too.
2) C++ or C# ? Whichever offers the more learning experience. My own experience with both mentioned technologies is limited, but I remember there used to be a Database Template Library (DTL). C# on the other hand will probably be faster to develop. I could be wrong. There are any number of free DBMS engines available on the net. Unless the assignment explicitly recommends using a text, opt for one of these.
3) I concur w/Brooks up there ^^^
Good Luck!

You are a university undergraduate. And you are talking about complete inventory system.
I suggest building a blog application first with all the best practices (like blogengine), then move to e-commerece sites (nopcommerce, dotcommerce). And then do whatever you like.
This is a common problem with undergrads like you, of jumping way higher without building any simple projects first.

As a full time PHP developer, PHP sucks! ASP.net is okay (mmm... no it sucks too), but it locks you into proprietary licenses.
If you're starting from scratch, go for node.js. It's c++ and server-side javascript. Yes, it's new, but it has engineering promise. It'll be more commonplace in a few years.
And if you're worried about performance, don't. Javascript in V8 is extremely fast.
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
Here are some node.js links to get you started:
http://www.delicious.com/homer6/nodejs
Enjoy.

How to prevent decompilation of any C# application [closed]

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 7 years ago.
Improve this question
We are planning to develop a client server application using C# and MySQL. We plan to sell the product on the shelf like any other software utility. We are worried about the decompilation of our product which does have some sort of edge over our competitors in terms of usability and bundled functionality.
How can we prevent our software from decompilation, so the business logic of the product remains intact?
We have heard about Reflector and other decompilers which makes our code very much vulnerable for copying.
Our customer base is not Corporates but medical practitioners who themselves may not do it but our competitors may want to copy/disable licensing or even replicate the code/functionality so the value of our product goes down in the market.
Any suggestion to prevent this is most welcome.

If you deploy .NET assemblies to your client machines, some kind of decompilation will always be possible using reflector and similar tools.
However, this situation isn't materially different to what you'd encounter if you wrote the application in native C++. It is always possible to decompile things - if it were impossible, the processor couldn't understand it either.
You're never going to defeat the expert cracker - they'll treat your security as an intellectual puzzle to be solved for the challenge alone.
The question revolves around how hard it is to defeat your licensing practices and the return on investment.
Sit down with a spreadsheet and look through the possible scenarios - the danger is probably less than you think.
Factors like "ease of use" are visible in your software for any user to observe - so you'd think it easy to copy. But, good User experience is rare (and seldom copied well), because most developers (myself included) are nothing like typical users.
I'd suggest you concentrate on making the job of a cracker harder, cause you can never make it impossible, just non-profitable.
One possibility to try: It's possible to pre-compile assemblies into native code as a part of the installation process. Paint.NET does this for performance reasons. I believe that once you've done this, you can discard the original assemblies and use the optimised, native code editions.

If it were me, I wouldn't be attempt to obfuscate; I would:
Not worry about it and aim to continually improve and stay in front
But secondly
Consider providing the 'secret' services over the Web. It's up to you to decide how critical and possible this is; but it does "prevent" decompilation, because the end user doesn't even have the code.

Google for .NET Obfuscator. You will find a lot of products that will help in this. Also there are related questions already asked in Stack Overflow.
Here are some:
Dotfuscator
Secure Team
EDIT: While searching for De-Obfuscating tools, I came across an open source tool De4Dot. This tool supports decompiling obfucated dlls created by most commercial tools and does a pretty good job too.

Intellilock has served our purpose well in terms of obfuscation as well as licensing. But I would not recommend the product as the support is not upto the mark. We never got replies in time for the problem we were facing. We had to search and research on our own or even change the business requirement to achieve some goals.
Via this answer I am not intending to promote or demote any software but just want make people aware about the product we are using so they can make wise decision.

The last time I looked into this, Spices.Net Obfuscator looked like the best thing on the market.
No, I don't work for them. :)

I use smartassembly. It is simple to use and also has the ability to send crash reports back too you built in.

The obfuscators others have mentioned are likely very good.
An alternative approach you might not have considered is to code some of the core business logic using a language that is fully compiled to machine code, such as C++.
The benefit of doing this is that it makes it far more difficult for someone to decompile your code. A drawback to this is that you have code in two languages to maintain. This might not be the best approach for your situation, but is useful in cases where only a small part of the code needs to be obfuscated while the remainder of the code is UI fluff.
As an example, your medical software package might be performing edge detection of say, certain glands for the purpose of telling a doctor the size of said gland. The algorithm for calculating the size of the gland from a bitmap image would be contained in a DLL written in C++.

to answer your question about the C++ wrapper around the .net code; I dont think it would work, because when you deploy the application the final c++ dll and .net dll containing the business logic code will be separate entities and the ones who want to get to your business logic would still be able to just pick out the .net dll and peek inside.

you might want to consider Remotesoft Salamander Protector
this is much better than anything else in that it makes it impossible to decompile to the high level language.
Of course, anybody who is an expert can spend enough time with your software and figure it out because it does decompile some,but it hides all the set and get methods
So, they can get a peak,but that is about it. they have to figure out the rest which lowers the probability of anybody just cracking it.
hope this helps

Writing on this thread after a long time. We have purchased a software called Intellilock which is helpful in preventing decompilation, obfuscation and also has a strong licencing module.
We did not go for .Net Reactor even though it has more prevention controls as Intellilock was serving our purpose well enough.

How can I become a better C# programmer? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When you can create classes and do the simple stuff (GUI, reading text files, etc...), where do I go from here? I've started reading Code Complete 2nd Edition which is great but is more of a general programming book. What topics should I learn next?

I'd argue that, at some point, it's no longer about topics. It's about doing stuff. You gotta write code an you've gotta write a lot of it.
People will often tell you to find some niche problem to try and solve when learning a new language and that's perfectly fine, but if there's an application or feature of an application that you really enjoy using or really admire, attempt to build it (or parts of it) yourself. Even more so, if you find your self wondering Hey, how does [this application] do that?! Try to build it.
Many of your projects may never see the light of day beyond your desktop, but the learning, experience, and tools you'll have under your belt will be something that you can carry over to each subsequent project.
You never know, though, one of those little hobby projects may end up solving a problem for someone.

Not to disagree with the folks who are saying "write stuff," but one topic that you should learn about next is the underlying fundamentals of the CLR -- the workings of the engine that sits behind all of these libraries. A good resource for this is Richter's "CLR Via C#."

Write a desktop RSS reader. You'll get exposure to a bunch of different areas (parsing files, graphical apps, HTTP, the flakiness of the internet), and you might actually use the result on a daily basis. Picking a specific goal or feature to work towards will help you learn more quickly than something abstract.

I agree with most of the answers so far, but I think that if you want to improve as a developer you can benefit greatly by not running solo. Try to find someone who can coach you. Over the years I've made my greatest leeps in depth of understanding by teaming up with programmers who were smarter and more experienced than I was. (They still are :-) )

Learn another language and apply the learned knowledge to C#.
F#, Scala, Haskell - lots to pick :)

Get ReSharper, keep all recommendations enabled and understand them.

Learn best practices and software engineering and how to apply them to C#.
Learn Version Control, TDD, Domain Driven Development, Continuous Integration, MVC, MVP, A handful of patterns: facade, factory, repository vs. active record, etc.
Learn tools that will help you avoid reinventing the wheel: Validation Application Block, NHibernate, etc.
I found this free e-book from the guys at CodeBetter a few days ago:
link text
I haven't read all of it but it looks like a good read.

Try reading the Mono source code to get a look at how a C# compiler written in C# looks. You'll learn so much about the language, compilers, and computer architecture. This is the great benefit of a project with source - you can learn from it.

Visit CodePlex.com and GitHub.com and look for open source projects which you can contribute towards.

looking at q/a of stackoverflow, c# topic. :-D

The best way to learn is to actually get stuck in and build some cool apps, websites, whatever. Its still a good idea to keep up with the various websites to learn new stuff that you might not have come across though.
Maybe build the next facebook or google :)

Also a good way is to get involved in a small project with multiple members (friends maybe), so you can learn from each other and see how other people do their stuff.

Read code
Write code
Test code
Read books (some suggestions), blogs etc.
Repeat

write good unit tests and try to get the code coverage as high as possible

Write code yourself, and read the code that has been written be someone else. But, not anyone else; of a person of whom you're sure that he writes good, clean, smart code.

Work in a team with better programmers - get employed
Work on large open source projects.
I disagree with most people here that learning by building stuff just by yourself is the best way.

Write code, lots of it. And not those fluffy little HelloWorld-type programs.
Find either a real project that interests you or something you've already written that can be converted to C# and do that. Only by doing (and, unfortunately, making copious mistakes) do we learn.

practice, look at open source projects, understand completely what it does and how it does it, especially complex libraries like mocking frameworks, ORM, etc

CLR via C# a great book !! helped(still helping) me a lot understanding the language also you can download the c# language specification book

If you want to become a better C# (replace with any other language), work on large scale applications, the kind that has certain features on 'musts' in it that you know you have no clue how to realize them, yet. All the easy ones around these core 'nuts-to-crack' will help you, too.. it's always good to get used to thinking in large, interwoven dependencies in projects which force you to think through and layout the architecture of your final product upfront.
This isn't particularly c# related, but if you want to become a better developer, these kind of projects (that implicitly include lots of ((c)lean) coding and testing etc etc) are the best learning grounds.
If none of the clients wants to 'give you the chance' to work on such a project with your current skill set just yet, go ahead (or in any case) and start coding on an opensource project and keep friends, colleagues and places like stackoverflow involved.
Be prepared and open to make 'errors' (as you might judge them afterwards)... because only with a gazillion errors made you see the slim/windy path in between them.
That being said, learn to not over-engineer or get tooo perfectionist too early. Bugs will be made, bugs may even remain in a final product considering certain impact conditions etc, learn to live with that as an engineer/developer.

Suggest you read C# in Depth. It is a deep dive into C# that will greatly enhance your understanding of the language. The author, Jon Skeet, is rumored to be a lurker on this site...

With a new language, try to solve some of the Project Euler problems. Improving math and coding at the same time!

How can I help junior members gain confidence in their ability to refactor code? [closed]

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 10 years ago.
Improve this question
I wanted to see what folks thought were the best way to help junior members gain confidence in their ability to refactor code. I find that often junior developers simply follow the existing patterns and sense an aversion to break anything due to the perceived risk. I am trying to get them to look at the requirements (new and existing) and have the code map onto the domain model versus "tweaking" or "bending" the existing code base to support new functionality. Just wanted to see if there were any folks who have success here. We are currently thinking about pushing more pair programming, TDD, code reviews etc., but wanted to check if there were other success stories...

The only reliable answer will be unit tests IMHO. Not necessarily TDD -- just get them to write tests for the existing methods/classes they want to refactor, make sure they're doing what they're doing, then allow them to refactor like crazy while relying on the tests to make sure the methods are still valid.
The confidence level and flexibility unit tests allow are immensely valuable in these kinds of activities.

It seems that pair programming with a senior developer in combination with writing tests would be the optimal situation. If the more experienced developer in the pair is leading, the testing will just be part of it.
Writing tests alone leaves room for improvement. Writing tests in a pair environment is the best of both worlds and therefore should build the confidence quicker.

I recommend you to have Unit Tests before start a heavy refactoring, if you have a good code coverage, by simply running the tests you'll be able to see if some test fail, which refactoring affected the desired program behavior.
Basically Unit Testing can give you the confidence your team needs to refactor.

No matter what, you should push for "more pair programming, TDD, code reviews etc". You should also make sure that your programmers (both Junior in years and in habits) are skilled in the fundamentals.
I reccomend suggesting that they read McConnell's Code Complete and Fowler's Refactoring.

I agree - unit tests, and pair programming.

The first step would be to have them write tests for whatever they want to refactor FIRST and then refactor. I also think there is some merit in code reviews with more senior developers as well as pair programming.

My suggestion would be to take a system that will change quite a bit over time and let a junior developer give a plan of what basics they want to apply to it, e.g. are unit tests missing, what design pattern may make sense to use to add the new functionality, do you feel this is "good" code and if not, what changes would you make to it? Part of this is getting them into the code and comfortable with it as when a developer doesn't know what anything within the system does, chances are they want to make minimal changes for fear of breaking something and the subsequent negative fall out. If there can be a senior member that can act as a mentor and guide what junior developers suggest into something that better matches what is being sought, this may be the big thing to get in there.
Note that for the above that senior member may have to have a good deal of familiarity and in a way already done the planning of how to make the changes that the junior developer will do, but the idea is to get the juniors more into the code is how I'd see it. If the junior developers can get in the habit of jumping into things and be encouraged to do that, then I can see some success there. The key is to have the idea of how to correct what the junior developer suggests and yet encourage them to give more into the overall process rather than be told what to do.
Some people are more likely to stand out and take a chance, the key is for the group to see how this turns out as what you want in the end is a group of junior developers all working on various solutions where the senior developer may have originally built the system or integrated various products together and thus can give an input on what should be done but act as a guide rather than a parent in getting stuff done.
Another way to view this is to simply visualize things from the junior developer's view. If they suggest something and get something, e.g. praise or better assignments, then this may get things rolling, though one has to be careful on what is given as to keep taking things up a notch can run into problems if it grows too high.

Ask them to write or investigate existing test cases
Run the those test cases, record the result
Ask them to refactor the code
review the refactor code
Run the test cases match the previous observations

Also, try doing some coding dojo's. One pair sits and programs at the beamer, rotating one developer every five minutes. Have them talk about how they refactor, and why.
See: http://www.codingdojo.org/

I believe the question is not specific to C#, so I'll suggest giving it a try with Java using Eclipse. Eclipse has the best refactoring tools I have ever seen so far (although I never tried IntelliJ IDEA or Resharper). I have benefited a lot by learning refactoring through Eclipse, especially using the Preview window before performing any change.

I would recommend a combination books, tools, coding and mentoring.
Before anything else - get the candidate to buy or borrow Refactoring by Martin Fowler and read it.
If you have a good source control system - it should be trivial to create a separate branch to play with. Also if the end result of the exercise is useful you can easily merge it into the trunk.
Next, pick a specific task that you know would require them to comprehend the application structure. For example, ask them to instrument a part of the system. This provides a task within which to work instead of general directives (like read the framework documentation or read this code)
The next part is to ask that tests be written to support the functionality touched by this task. Review the tests and encourage writing of comprehensive tests. It is important to use a tool for this like NUnit or if your IDE supports unit testing, use that. Encourage the person to ask questions and find out why things are the way they are.
If you are using an IDE that supports it introduce the refactoring tools in the IDE and encourage them to refactor the code. Use pair programming or regular code reviews to mentor the person. The tests can be used to show how unit tests are a vital part of a good refactoring effort. Start small - may be change the names of things or extract fields into properties and then move to more complex ones.
Hopefully, by the end of the exercise, not only will the person be comfortable enough to question, tweak and change the application and you would have some useful functionality out of it as well :-)