Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Anti-virus, malware, botnets and the like are becoming larger and larger parts of our daily lives. Are there any resources that discuss creating anti-virus tools, security tools and such? Seems like an interesting topic, but I have not been able to find any real source to refer to in order to learn more.
Suggestions? (Good and bad?)
I assume most languages used for this are C++ or assembly? Or are there others that work well for these sort of items?
Alex's suggestion of Bruce Schneier's work is excellent, and everyone should read his stuff, but probably won't address what you're talking about. Even so, you should read it. He's the clearest writer on security topics today, and a voice of sanity in an often hysterical industry.
A free place to start for the bare bones is the SANS reading room. It's far from enough, but it's the basics.
I was fairly pleased with The Shellcoder's Handbook. It's a good introduction with some practical code to work with. It shows how real exploits are written, which is the first step in understanding how to protect against them.
Exploit work is done in a variety of things, but for the classic stack-smashing attacks, you need to know C and the assembler of the target platform (generally Intel). C++ is much less common in this world. It's too twisty-turny by the time the compiler gets done with it, and too bloated for the kinds of things needed. Objective-C is almost more useful in my opinion so that you can understand Mac reverse engineering. But that isn't where security is usually done. In this I'm speaking of exploits themselves. Many security tools are of course written in C++.
For the security tools side, you probably want to ask on serverfault. There are many, and the SANS link above should have links to some of the common tools (Nessus, nmap, hping, metasploit and the like). sectools.org maintains a big list that I like.
If you're going to be a security developer, you need a lot of breadth and a lot of depth. You need to understand the network protocols as well as the code that talks to them. You should be reasonably comfortable in languages from assembler to ruby. Much of it is more a way of thinking than an actual skill set, but those who are good at it tend to have broad skills and pick up new things quickly and often.
Since you noted specifically detecting and monitoring for exploits, you should dig into tools like snort (for learning how to detect) and metasploit (for generating the attacks to detect).
go to http://www.milw0rm.com/ to see the exploits.
For a holistic view on security, anything by Bruce Schneier comes highly recommended -- not the threat-specific focus you have in mind, but a background that will make you more effective at security issues in whatever role you play, whatever background you have.
For more specific views, I would recommend this book (and just about every book I've looked at in depth in the same series, but I can't personally vouch for all of them, they're dozens!-).
As well as what Alex Martelli posted, this book might be something you can consider.
Related
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
One of the Four Core Agile values says "Working Software over comprehensive documentation" and this is explained as a good thing. Furthermore it is explained that rather than written communication (e-mails included), face-to-face meetings are preferred and "more productive".
I would like for someone to explain to me why or how is this a good thing?
In a organization I used to work there were heaps of working software that I had to maintain. The documentation was minimal and it was a nightmare. It didn't help that the programs were not modularized and were very hard to understand and with the most esoteric twists and very disorganized. Comprehensive documentation as very important was one think I took from that experience. It doesn't matter if the software works now if it is not going to work in the near future right?
And on face-to-face meetings, I had the same doubt. I very much prefer e-mails (written) You can say the most outrageous of things when talking but when it is written then it is a deal. Plus if you are in a multinational organization with several languages, it helps a lot
I would like to hear the voice of people with Agile experience. How is the above a good thing? Thanks
Working software over comprehensive documentation
Comprehensive documentation is sometimes seen as a way to demonstrate progress. "If we have a detailed specification and a weighty design document then we are making good progress towards a product delivery"
What working software over comprehensive documentation means is that we view working software as a better demonstration of progress than documentation. This is because comprehensive documentation can give a false level of confidence.
So there is nothing that says avoid doing any documentation. It is just saying that we should only do the documentation that is needed and not just do documentation because it is part of a process.
In your example where there the software is difficult to work with then more documentation may well be needed. Just don't write documents that never get used and offer little value.
Individuals and interaction over process and tools
Face-to-face communication has many advantages over other forms of communication. For example:
People use body language to give context to conversations
People use audible and visual clues as to when to start and stop talking - this helps to make conversations flow
Regular face-to-face discussions often help teams to bond together
Notice though that the Agile manifesto does not mention face-to-face communication. All it says is individuals and interaction. If you and your team have ways of communicating that are as effective as face-to-face communication then that fits just as well within the Agile approach. The important part is that we value interaction and having members of the team work closely with each other.
When all agile recommendations are taken into account there are no issues you mentioned in your question. Working software should also has good code standards and design.
Regarding your particular issue with a lack of documentation unit tests (TDD/BDD) could be very useful. Good code coverage can explain how code should work even better than detailed documentation. Agile methodology also welcomes simplicity so your entire architecture might be over-complicated
Regarding face-to-face communication. Just imagine situation when you detected issue in your product (web-site markup). Instead of writing long email with steps to reproduce and attaching screenshots, you just go to front-end developer sitting in your room or make skype call and start explaining problem. Developer quickly realizes that he forgot to include some script. So your will get answer in minutes while your email can be answered next day.
I think it would be necessary to clarify your needs on using agile first before you want to apply agile.
Agile is the recommended working framework for a highly unpredictable domain(you may also check Cynefin model for identifying your working contexts). In this domain, you do require "working software" and "good communication" to review and revise your development in a short-term iterative process. As a result, you can change and improve your software based on the feedback from your software. This is proven to be the most effective and efficient way to build software in high competitive business world.
However, in your organization, you are maintaining legacy software with limited documentation. This context is totally different from what agile is designed for. You need optimization in your world, not testing or growth seeking. In short, process/tools and documentation are more important.
Regarding email communication, there is no doubt that email makes the deal, but you could never make a deal by just using email. It is the same as how you apply agile. You should apply both face-to-face and email based on different situation.
I would regard Agile as a framework more than a methodology. The concept there is to allow you build your own process based on your own working environment.
Documentation is an expression of a shared vocabulary, so it should be consistent from the epic all the way down to the comments in the code:
Documentation should be comprehensive and understandable. Using examples is recommended.
Language between feature stories, technical stories, pseudocode, and assertions should have naming conventions
A feature that people do not know about is a useless feature.
Lack of documentation can be a symptom of the lack of a marketing plan
A feature that isn't documented is a useless feature. A patch for a new feature must include the documentation.
Lack of documentation can be a symptom of the lack of usability, accessibility, and information architecture
Adjust the documentation. Doing this first gives you an impression of how
your changes affect the user.
Lack of documentation can be a symptom of a lack of focus on the user and the maintainer:
Software is not useful by itself. The executable software is only part of the picture. It is of no use without user manuals, business processes, design documentation, well-commented source code, and test cases. These should be produced as an intrinsic part of the development, not added at the end. In particular, recognize that design documentation serves two distinct purposes:
To allow the developers to get from a set of requirements to an implementation. Much of this type of documentation outlives its usefulness after implementation.
To allow the maintainers to understand how the implementation satisfies the requirements. A document aimed at maintainers is much shorter, cheaper to produce and more useful than a traditional design document.
And understanding the purpose of any project requires building a relationship between the project timeline and the source code history:
Write the change log entries for your changes. This is both to save us the extra work of writing them, and to help explain your changes so we can understand them.
The purpose of the change log is to show people where to find what was changed. So you need to be specific about what functions you changed; in large functions, it’s often helpful to indicate where within the function the change was.
On the other hand, once you have shown people where to find the change, you need not explain its purpose in the change log. Thus, if you add a new function, all you need to say about it is that it is new. If you feel that the purpose needs explaining, it probably does — but put the explanation in comments in the code. It will be more useful there.
References
Vim documentation: develop
SCRUM-PSP: Embracing Process Agility and Discipline (pdf)
Secure Software Development Life Cycle Processes | US-CERT
An Uneasy Marriage? Merging Scrum and TSP (pdf)
TSP/PSP and Agile-SCRUM: Similarities & Differences
GNU Emacs Manual: Sending Patches
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
The amount of available programming languages is both a bless and a curse, I think.
I know a lot of programming languages already, some at syntax-level only and some good enough to do actual coding (Python, C, C++, Haskell, Perl, BASH, PHP, and lots of others). I have been programming for almost as long as I've been intensivly using computers (6 years), in almost every paradigm (functional, imperative, object oriented), but I don't feel prepared for the software industry.
I've been writing a lot of bigger programs in a lot of different languages, mostly network based, including large multithreaded server/clients, and I still don't feel prepared!
Currently I'm obsessed with my "3-tier" plan, which includes a high level language like Haskell, an interpreted language like Python and a low level language like C, yet I don't feel good enough!
I know how to work in teams, and how to work along given guidelines, but I'm unsure.
Am I prepared?
Please, kind people of stackoverflow, help me out of this mess! :(
Thanks for all the answers, I wish I could chose more answers as THE answer :)
Sounds like you know an awful lot about programming, but you don't mention anything else. Being a software developer requires more than just programming as a technical skill. Brush up on topics such as source code control, unit testing/test-driven development, continuous integration, etc. Hopefully you'll land in a job where at least one of those is in use. Try and learn as many useful time-savers as you can with your tools; try to become as flexible and efficient with your IDE as possible.
Elsewhere, don't forget to develop the more personal skills; attitude and work ethic, and more related to your field, issues such as eliciting requirements, documenting issues and describing problems and solutions. Don't worry too much about these if you're going in afresh, because you're not expected to have a huge knowledge of them, but if you're at least aware of them and trying to improve, then you have a greater chance of doing so.
Try to appraise yourself of general software development issues that aren't directly coding, if you haven't already - general attitudes to security-oriented development (and testing), good design and similar best practices.
Don't sweat too much about being perfect right off the bat. If you've got no room for improvement, you aren't going to enjoy your career very long, and burning out as a programmer ain't much fun.
You know enough - there is a minimum threshold of knowledge required in the industry (which is above what some developers have), but it sounds like you are already there.
For anyone with the aptitude, new programming languages, techniques, etc, are easy to learn. A good company to work for will hire you based on your abilities, not knowledge (which can go stale very quickly).
If you want to stand out as a software developer, ensure you have rock solid communication skills for reports, e-mail, telephone, meetings, etc. That is a rarer gift in the software field, and although it is not necessary more valuable at the junior levels, it pays off in the long run.
The single most important thing I can think of to be successful in the industry is to be able to respond quickly and efficiently to change.
I recently took a programming test which I thought was a good and fair test. I passed it without a great deal of effort. I was told that 50% of the people (these are all people with programmer on the resume) don't even know where to start. Your earnestness and desire will most likely put you in the top third of most places to start with.
Knowning languages is not all you can do.
If you can, a placement/internship will do wonders. Anyone can program. Real world experience will teach you more than any tutorials, self learning or schooling will.
Naturally, gaining an internship requires some experience, so it's very much catch twenty two.
If going for an internship is not possible, get involved with an open source project. You'll find you'll learn loads by working with people smarter than you.
True knowledge exists in knowing that you know nothing.
Socrates some smart dude
I think this is pretty common among developers. Imo it´s a way better sign then if you would come to the conclusion that you were fully trained.
The only way to know for sure if you're prepared is to try. Sometimes being thrown in the deep end actually helps and you'll find you learn more in that first real world job than you did in all the books/etc that you read in the years before. Also, knowing multiple languages helps you understand underlying semantics of programming in general, but in a real job you'll likely be sticking to one or two languages day to day, so don't get hung up on knowing every language out there.
It's better to try & fail than to spend your life wondering if you're ready.
Go to dice or monster or whatever your favorite job site is and see what people are looking for. It's not Haskell, it's C++. Learn that well and you're ready to go. Once you're out in the real world, you'll learn quickly enough the things that are important. These are mostly the soft skills that school doesn't teach you. Things like how to get along with the clueless, how to present your ideas so they'll actually be considered, and how to see the forest even though you're stuck under a rock.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I spent a lot of time recently reading about debugging. One of the aspects that was continually referenced was not just a bug-tracking system, but a bug-solving process. I read about people writing down takes on the problem(that did or didn't work), tests that would determine if a given take on the fix would work or not, etc.
So I am thinking, "hey, this is a good idea"
I use Mantis right now, and it doesn't seem to have that capability(without abusing its fields). Mantis works great as a bug logger. But I'm looking for something more sophisticated in interface, I think.
Example
Suppose my bug was "Pants fall off". Then I want to log this information as...
"Pants fall off; Feb 32, 2009, 25:61; when I walked into a room, my pants fell off!"
Developer 1...
Hypothesis 1: Pants too big.
Test 1:Put on a belt.
Possible Solution 1: Buy a belt.
Result = ?? Result ???
Test 2: Put on your kid sister's pants.
Possible Solution 2: Steal into her room and take all her pants while she's at school!
Result = ??, date/time = ???
Developer 2...
Hypothesis 2: Your pants have holes in them.
Test 1: Shine a light on them.
Possibile Solution: Buy new pants.
Result = ???, date/time = ???
Now, this is a silly example. But I think it would be great to have as a software tool.
Does such exist, and if so, what's it called?
Trust me: you really don't want to maintain your bugs, that's why you don't find "Bug Maintenance Systems" :-)
Sorry... couldn't resist. Regarding the actual content of your question: I personally just keep track of all that information in the comment history of the ticket. Mostly I use trac for its simplicity, but also the capability to link into sources if required (at least on the file level, I wish it would grok code so you can point into the AST).
You could use Testopia, which is an extension of Bugzilla. This, of course, would also mean you would need to use Bugzilla.
Taken from the Testopia website:
Testopia is a test case management extension for Bugzilla. It is designed to be a generic tool for tracking test cases, allowing for testing organizations to integrate bug reporting with their test case run results. Though it is designed with software testing in mind, it can be used to track testing on virtually anything in the engineering process.
We also use Mantis, and like Peter Becker describes, we use the comments to describe the work on a bug. This usually works, because most bugs don't have such a long history.
If work on a bug becomes so complex it needs its own meetings and meeting notes, we usually create a task in our main work planning system and do the discussion there (linking from Mantis). That at least works for us.
At any rate, I'd be wary of a system that tries to explicitly support a certain workflow, as these also tend to lock you into the workflow they expect. An in bughunting, the workflow can vary a lot from bug to bug...
Finally, note that Mantis also lets you edit your comments. So you can change old comments to avoid cluttering the bug report.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I have long been of the opinion that the time and resources it would take to write a piece of malicious software, of whatever type, could better be spent on other things. However, as a developer I am constantly worried about the possible security flaws in systems I work on.
Of course I know about validating input, I understand fully how code and sql injection can work and obsessively sanitise against these risks. Also, whenever I am able, I bone up on new security risks with whatever resources are to hand (e.g. articles, whitepapers, presentations etc.) but I often feel I'm missing the point, maybe because most of my knowledge could well be classed as "new-fangled" (C#, MSSQL, PHP, some Python, a smattering of Ruby): the oldest language I know is Classic ASP.
Sometimes when I read about things like Cross Site Scripting and URL hijacking I read the articles upon which they are based but I feel like I'm not following 100%.
What are the best resources you know to get to grips with security concerns and really understand how they work? Could be anything, books, websites, other types of resource. I know I don't know enough about these issues so where could I go to learn more?
http://www.owasp.org/
Well, you could start with a recent post from Jeff:
Top 25 Most Dangerous Programming Mistakes and work your way forward from there.
Try James Whittaker's How to break software security
One Monkey,
The fact that you are asking the question means you are well on your way. The real issue is that so many don't ask, are not worried as you are.
One thing I would modify is change the thought that you know some security issues fully. There are some really devious little jerk-offs out there. I am of the opinion you are better off assuming they are smarter than you and so bolt things down as tight as possible. I find it is a better mindset.
Two resources you should look at:
XSS Cheat Sheet
A good example of SQL Injection
I must admit to being somewhat surprised at the lukewarm response to this query. Does this mean:
a) everyone else knew about OWASP and I'm way behind the curve?
b) everyone else is confident enough in the security of their code to not need a little help staying up to date?
c) no one else cares?
d) other?
I have found the reference to OWASP most helpful, so far I'm about to install some of their project software to see how it works, once I feel that I'm better off security wise for having a look at their site I'm marking that answer as accepted, unless something better comes in in the meanwhile.
http://www.securityfocus.com/ and the categorised mailing lists.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm supposed to learn how to use LabVIEW for my new job, and I'm wondering if anybody can recommend some good books or reference/tutorial web sites.
I'm a senior developer with lots of Java/C#/C++ experience.
I realize that this question is perhaps more vague than is intended on stack overflow, so how about this? Please answer with one book or web site and a brief description. Then people can vote up their favourites.
It will take some training and some time to learn the style needed to develop maintainable code.
Coming from Java/C#/C++, you probably have a good idea of good software architecture. Now you just need to learn the peculiarities of LabView and the common pitfalls.
For the basics, National Instruments offers training courses. See if your new employer can send you to a Basics I/II class to get your feet wet. They offer some online classes as well. Following classes, you can sign up to take tests for certification.
Get an evaluation copy of Labview from National Instruments; they have a well maintained help file that you can dive right into, with example code included. Look at "Getting Started" and "LabVIEW Environment". You should be able to jump right in and become familiar with the dev environment pretty quickly.
LabVIEW, being graphical is nice, but don't throw out your best practices from an application design point of view. It is common to end up with code looking like rainbow sphaghetti, or code that stretches several screens wide. Use subvi's and keep each vi with a specific purpose and function.
The official NI support forums and knowledgebase are probably the best resources out there at the moment.
Unofficial sites like Tutorials in G have a subset of the information found on the official site and documentation, but still may be useful for cross reference if you get stuck.
Edit: Basics I/II are designed to be accessible to users without prior software development experience. Depending on how you feel after using the evaluation version, you may be able to move directly into Intermediate I/II. NI has the course outlines available on their website as well, so you know what you're going to cover in each.
LabVIEW for Everyone is recently revised and quite comprehensive. Other than the free stuff available on the Web, this is probably the best place to start learning the language.
The LabVIEW Style Guide is a great book on how to organize and arrange your code and files for maximum benefit.
Object oriented programming is a recent addition to LabVIEW. The LVOOP white paper explains much about how it works and why the way it is the way it is.
It's a bit out of date, but LabVIEW Advanced Programming Techniques by Bitter, Mohiuddin and Nawrocki is still full of useful stuff.
The National Instruments forums are a great place to go for basic help. The LabVIEW Advanced Virtual Architects (LAVA) is the community forum for advanced topics.
Tutorials in G, also check out the webring.
-Adam
The official NI support page and support forums are hard to beat.
It really helps having a guru around for LabVIEW.
'Arc the daft' pretty much nailed exactly what one should try to do to learn LabVIEW. However, I would not skip Basic's I and II. The classes do teach basic programming concepts and are geared to non-programmers, however they do cover the IDE extensively. The LabVIEW IDE is strange coming from a text based language and spending the time in the class learning it with an instructor can really accelerate your learning.
I would skip Intermediate 1 if you are a seasoned developer. Intermediate 1 tries to teach software engineering practices in the span of a three day course. If you are studying to get your CLD you need to know the course and the terminology for the exam, otherwise I wouldn't spend my time or capital in the course.
Subscribe to the Info-LabVIEW mailing list. It's got a lot quieter in recent times as the NI and LAVA forums have grown in popularity, but it's still read by some very experienced and helpful people, including people at NI, and if you can't find what you need elsewhere then a good question will usually get a good answer.
The NI style guide, as already mentioned, is a good reference - re-read it as you learn about more of the things it covers, it contains some densely packed good advice.
Personal top tips: look at the supplied example code (although it's not necessarily perfect); learn to use queues and notifiers as soon as possible; don't dive in to using event structures and control references until you've figured out what you can and can't do without them; and start small and simple - you should find it easy to reuse this code later on by repackaging it into subVI's as the scope of your ambitions increases. And have fun!
For me the best way to learn LabVIEW was by analyzing the in-build examples. The best forums are NI Developer Zone Community and LAVA Forums
LabVIEW is really easy to work with but the tricky bit is to know how to design your application so that it will not becaome a spaghetti. Once you get the basics (e.g. LabVIEW Introduction Course) learn how to use design patterns, events, queues, typedefs and references. Use modular architecture, avoid big structures, try 'writing' your code in small window.
It is also important to know the differences between LabVIEW versions (full/pro, and ver 7.1.1, 8.2, 8.5, 8.6, 2009), how to use version control system with the vi's (binary files), and how to keep your files in project so that you can easily reuse any code and be "DRY" (don't repeat yourself), how to build executable and what LabVIEW RunTime Engine it needs (for customers), what is DAQmx and how to use it, what are VISA drivers and which version is correct for you settings, how to use Measurements & Automation program..
When I started with LabVIEW a few years ago I was given a link to the LabVIEW Graphical Programming Course. It covers the basics and having a sound knowledge of other programming languages I think helped me pick things up quickly.
I would start with the LabVIEW wiki.
Specifically, LabVIEW Tutorial. There are lots of online references and links to LabVIEW reference books. Welcome to the world of LabVIEW!
I would suggest you start with LabVIEW for Everyone. Its a good book which covers the basics of LabVIEW well.