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.
I was wondering how can I be sure about safety of code in open source projects, particularly the ones with thousands lines of code, including calls to popen() or system().
How can I know there is no harmful and malicious code in there?
Is there anyway I can examine the code safely?
I was wondering how can I be sure about safety of codes in open source projects
The short answer is that you can't.
Yes, in theory, you could go through the whole code base and audit it, which you can't with proprietary code, but who has got time for that? On the other hand, a lot of the bigger projects tend to have large numbers of volunteer contributors eyeballing the code all the time and the organisations that run them (e.g. Apache and GNU) have ostensibly benign motivations, so I think, malicious code would probably be found and flagged pretty quickly.
Having said that, I can think of one totally disastrous security flaw that affected Open Source software and was not detected for two years. It arose precisely because it was possible for a third party to modify an insanely complex (and badly written) open source product. The person making the modification did not understand what they were doing. Who'd have thought that was possible when they can read the code...
You can never be 100% sure of the safety of any code of any project, open-source or not. When using any code or software you did not write yourself, you inevitably assume a certain level of trust of the third-party author(s). If the project is open-source, you can audit their code to your heart's content, but as other responders have already pointed out, it is unlikely that you will have the time/resources to perform a full, line-by-line inspection.
You might find Ken Thompson's "Reflections on Trusting Trust" article an interesting read for further reflection on issues like this:
http://cm.bell-labs.com/who/ken/trust.html
Because it is open source, you can examine the code. As can others, so the safety is potentially much better than that of closed source, where a (very) limited number of people see the code. Your version control system (git) calculates checksums to detect changed code.
Often looking for ten minutes at the source code is enough to decide not to trust software. Where there are many alternatives, that suffices.
I should also add that apparent (and, in theory, verifiable) lack of malicious code in open-source projects does not guarantee their safety.
The reason is security bugs exploitable by malicious input.
For example, your favorite open-source picture/document/whatever viewer (or web browser) can have one or more of those bugs. If you open a maliciously crafted file with it, you can get pwned.
While I cannot definitively state that open-source software has more security bugs than commercial software, I'd warn you that if it's not an extremely popular project and if nobody's responsible with their money for the security defects in it leading to you getting pwned, chances are there are such bugs and there are very few people who are interested in and fixing them. I mean, programmers love to build. It's fun. Security is hard and often secondary to that.
Related
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 11 years ago.
I have graduated from my university almost a year ago. Since then I have worked with many different technologies, such as PHP, JQuery, ASP.NET, C# etc. Recently I have switched to a company where powerbuilder is being used for development.
The problem is that I haven't mastered any of the above languages. I can do stuff with those but when it comes to the complex tasks I often struggle with it because I don't have enough deep knowledge about it. After looking at powerbuilder for a few days I sense that this is going to happen again because most of the application code have been done using some sort of library which requires some advanced level of skill on powerbuilder.
My question is, is it OK for me to work on different technologies without mastering a single one of them?
If you choose to specialise the you are taking an opportunity cost by making yourself unavailable for other types of work. This is good if you can be confident that your chosen specialisation will last for a reasonable length of time. However, you can guarantee (along with death and taxes) that software will change. You will always be required to learn some new framework or approach in order to remain current.
So to avoid finding yourself at an intellectual dead end (are transputers still in use anywhere?) you should adopt a doctrine of constant learning. Learning is usually fun and almost always leads to a joy of discovery of some new tool or design. And never keep this knowledge to yourself (it only has a half-life of 18 months anyway). Share what you have learned with others.
So to answer your question: don't specialise.
According to the Pragmatic Programmer book, one of the tips for a good programmer is:
Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
This means that you constantly have to use, or learn about, new technologies. While becoming a master in one particular technology may be rewarding, technologies come and go, today more quickly than ever. A mastery in one particular programming language, tool or API may make you a guru today, but may mean nothing tomorrow.
IIRC they also recommended developers to master several technologies, but remain versed in many - at least in the sense of having heard about them, played around with them, being able to engage in a conversation about them.
So, I would say yes - specialization is necessary, but this doesn't mean one should ignore domains outside his own.
There is no 'right answer' to this question other than maybe, 'it depends'.
You will find it easier to find better jobs if you specialise, as you call it. I would think of it more as working with a specific language/framework. Further, it is important to solve difficult problems and gain experience, irrespective of the language chosen.
Once you've accepted the above as a truism and specialised, then I would suggest that you branch out and learn new languages. Fortunately, languages become easier to learn when you have more experience.
However, more than anything, you have to look at keeping yourself interested over a long period of time. That is the real key. If you have interest, you will continue learn and gain experience. Maybe that will mean you do something that is not particularly relevant to most jobs, such as writing a language compiler. Or maybe you will find that the rush of working for big clients on big projects is more important than a specific language/framework.
So that's it - just keep interested, and keep learning. And, where possible, build focus in the thing that interests you, as that will make it easier for you to find employment going forward.
It is important to be specialized in at least one programming language/platform, especially early on in your career. By specialized i mean reading a book about it, cover to cover, and having extensive hands on experience developing for it, at work or participating in an open source project.
The idea behind this is that when you specialize in a language, you will learn many concepts that you can carry over to different languages/platforms. e.g: The master of a language can master another with relative ease.
Further on in you career being exposed to many platforms is a good thing, as you start to shift from begin a developer to a developer/architect, and you need to make decisions about which platform to use, the pros and cons of each platform and so no.
So my advice is try to master at least one language, along with its tools and frameworks. After that you can move on to different platforms. It is important to use the right platform for the current project, you will need to determine that case by case, with the assistance of a senior developer.
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.
Coding a new 3D engine is fascinating but I there are so many out there. Is it sane for a programmer to start a new one? Are there industry sections in need?
Reasons to do it:
You want to learn about how to make a 3D engine, and don't really care if anyone but yourself uses it.
None of the existing engines do what you want and it's too much trouble to modify their source code (if you can even get it).
You have such an awesome idea and no other engine has done it so you need to do it because whatever you're doing doesn't exist yet.
Reasons not to do it:
You don't have enough of these resources: time/budget/expertise.
An existing engine fits your needs perfectly.
There are lots of reasons to build a new 3D engine (in no particular order):
The old one is a first person shooter, but you want a flight simulator.
The old one works, but isn't easy to use or has too many bugs
Someone else owns the old one
New hardware feature XYZ is fundamentally incompatible with the old engine
Someone is paying you to build one
You've never built one before.
Your game (simulation) only needs χ, but the old engine provides χ, ψ, ζ, α, β, γ, δ, and even π.
I happen to be building an OpenGL-based 3D engine in my off time right now. By implementing it myself, I'm expanding my basic knowledge of OpenGL way more than I would have by programming to someone else's interface (way more than I did when I implemented my own software affine texture mapped engine years ago). The downside is that I may never finish it :)
Generally, you code one if you have a need for one and there doesn't already exist one that suits your need.
Is there someone out there who needs an engine built for them because there doesn't exist one that suits their needs? Probably.
This is highly similar to the question should I write my own program/technology/framework X instead of using an existing one?" and that has been asked plenty, so I won't go over the usual boilerplate reasons.
While the answer to this question will always be somewhat subjective, a great deal depends on the context in which it is asked.
If it's being asked along the lines of I want to learn about game engines and rendering then it always can be beneficial to write your own game engine as developing the code is arguably the best way to learn. However, there may already exist good open sourced well documented engines to learn from as well.
If it's a commercial endeavor, then it's more of an issue of whether or not an existing engine provides what is needed. Modern commercial engines are written by some truly brilliant people and contain all the latest bells and whistles so it's more than likely they would suffice. This is evident by the sheer number of games that have been developed on two of the most popular game engines: idTech and Unreal engine. However, there still may be no tech related prohibiting factors to using an existing engine where writing your own is better. Such as if it can afford to be done, whether the engine can be licensed adequately, and, if the license can be afforded.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Often, I am told that Security functions are not available at a level of abstraction that a developer with little security knowledge can use them. What changes will the developers want in their developement environment say for Java that will make securing their software much easier than today.
I am looking at new ways like providing configurability at the level where the programmer just has to declare the security function he desires and the level he wants and only really power programmers will need to go and do something really extra.
So 2 part question - what services will you want as a developer and how would you like it to be integrated into your IDE (your development environment) so that you can easily use it.
where the programmer just has to declare the security function he desires
That's like asking "What type of scalpel can I buy so I don't have to learn doctorin'?"
You can't.
The issue of "security" covers a very broad range of concerns. You don't just "turn on security" and it's done. Security issues involve guarding your software from an ever-growing number of malicious behaviors.
At the root of it, computers have to let people do things. To give users that freedom, people will always find ways of getting into things they are not supposed to get into. The people who write operating systems, frameworks, and development environments can patch holes and abstract away some of today's security concerns but new ones will always be developed. Daily. It's a moving target.
Security is complicated because you have to know what types of vulnerabilities your application can be subject to. The only way to learn that is through vigilant study and experience.
You can't just flip a switch.
The more I think about it, the more I realize that what you want actually exists. Programmers tell the computer what they want it to do in a very specific manner, using well defined languages. The computer is expected to do exactly what the programmer dictates, within the definition of the language. If the programmer wants security, s/he can already tell the computer to act in a secure manner - such as using String classes in C++ to avoid buffer overruns with char arrays.
Of course, this isn't enough. Programmers still get things wrong, so language designers try to help with things like Java. In Java, buffer overruns are much harder to exploit beyond a simple application crash (char[]c = new char[1]; System.out.println(c[10]);).
But that's not really enough - the compiler can have bugs that will insert overruns, or the virtual machine may have such bugs. And other vulnerabilities will exist - like bad permissions on files, or exploitable race conditions (aka TOCTOU).
As we find vulnerability types, we can take steps to prevent them (developer training, new language features, new compiler features, and new OS features), and we can take steps to identify them (dynamic analysis, source code analysis, binary analysis), but we can't eliminate all bugs. This is especially true as new technologies come into play (once XSS and SQL injection were understood, developers started introducing LDAP injection).
OWASP is trying to do this with it's ESAPI project.
The best way for security to work is to have it built into the API, with very context-aware, context-specific programming methods. This is what SqlParameters do, in .NET, and similar things in other languages (they grab as much context as possible; types of variables, and so on, and perform validation).
If you want to get involved, you can probably get in on the OWASP action, as long as you are motivated.
The best way to do security is to let someone else do it, and follow the API and instructions to the letter. But also, you need to have significant trust in the people doing the underlying work, and you need to stay up to date with what is happening with the libraries you use.
On that last point, you also need to stay flexible. If it so happens that a vulnerability is discovered in your underlying system X, then you may need to update or remove it completely (but most likely update). You need to have the facility to do this ASAP. I.e. to swap out hashing functions, or to change encryption routines.
Obviously, this area is complicated and interesting. I suggest to you that OWASP is a good place to get started.
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 11 years ago.
Are there any statistics for this? I realize it must vary from person to person, but it seems like there should be a general average.
The reason I ask is that the company I contract for has multiple software products, totaling ~75,000 lines of code - and they seemed disappointed and shocked when they ask me a question about a specific portion that I don't immediately know the answer to (I am the only programmer they have, and did not author the majority of the systems) They think I should just know it all from memory. So I wanted something like a statistic to show them that an average programmer couldn't possibly have all that in his head at one time. Or should I?
You should remember where to find the needed stuff not remember it itself.
You should also be familiar with code structure and architecture enough to make an educated guess where a problem might originate and where you could possibly find the stuff you know exist but not sure where exactly.
You brain works like cache. The stuff you used recently is kept there, more older entries are erased. But there will never be enough memory to remember the code all at once. Because then you will want to remember all API functions, then all specs, then something else. This all is not feasible.
And being surprised with you that you don't remember all the code is probably one more instance of those perversed notions of how programmers do things. Ignore them.
It depends not only on your memorization skills, but also a lot on the code. Obviously, clean, idiomatic code is much easier to memorize than a badly written inconsistent mess.
Probably because clean code can be broken down into much larger "abstract tokens".
Indeed interesting question but I am in doubt if there is adequate answer at all. Here are only obvious factors I see right from the start:
Overall design quality. Even if you are new in well designed code you can very quickly identify where you should look to get answers.
Project documentation quality. For poor documented projects even developers that are in project from the start can't say anything about some parts.
Implementation quality. OK. You have good general architecture, good documentation for interfaces but even one really bad programmer could break all of this. This is because many companies are very strict about code reviews and I think it is the only one technique to prevent such situation.
Programmer experience. As you move ahead you see number of 'already known' code "bricks" in software new to you and experience is great help in this so contractors are often very experienced specialists familiar with various approaches and this gives average contractor ability to move much faster then full time programmer which is brilliant but worked 10 years in only 1 project context.
General person smartness. My opinion this is really not so important as most of others factors but it is really important.
... but the common problem is often companies hire contractors for some existing software improvement and they simply think this is only about to hang picture on the wall. You should perform some negotiation to force them to understand part of work is to understand what really should be done to meet their requirements at all. And such "learning" requires resources and is part of work itself. But I think it is slightly off-topic for StackOverflow (despite I voted up ;) ). Is it more for Startups discussion?
Even if you have written all that code you might forget portions of it. But you'll be able to recall it once you review it.
I think its natural for a programmer to forget some portions of his/her code after a long time.
Ask them how they want you to spend your time: surveying vast amounts of code you didn't write and perhaps writing up internal documentation, or whatever currently keeps you occupied It's not a facetious question. If they want quicker response to new issues, they need to invest in research.
I don't think there's a meaningful answer to this measured in LOC. As a manager, what I want to know is that someone in your situation can answer a question in a reasonable amount of time -- and unless I know you're in the middle of something, I wouldn't expect that 'reasonable amount of time' to be 'instantaneously'.
You should be able to understand all the components within the system and how they interact so that when there is a problem you can isolate one or two likely components and drill down.
I find it helpful to draw a few diagrams and keep them handy so I can use them to communicate with my boss\customer as well as jog my memory.
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.
What type of client is likely to support XP (Extreme Programming) practices?
I'm working for a company which is doing Agile (not strictly XP, but still applicable), and our client base is exclusively government organizations. Once they saw the results of the agile process at work, even those who had requirements to provide documentation in a Waterfall like manner were more than happy to continue to reap the benefits of the agile process.
And, yes, I agree with vfilby. Your customers should care about the results, not how you achieve them.
If your team achieves great results with a proven track-record, then companies desiring a successful result. If the converse is true, only companies who are wandering blindly will be interested.
There is the odd case where the client will want a certain practices followed. Like a experienced dev manager outsourcing a project to an external firm, or potentially a client who has heard that XP is good in passing but has no real knowledge or experience with it. In the former the experienced consumer will know what he wants and if you do not provide those services they will go elsewhere. If you try to fake it, they will know and be most displeased. The later, it doesn't matter so much as long as they get good results and think it was their own wisdom that brought them forth from the ground.
Either way, it is results that matter.
Now begins my diatribe which so far has inspired much ire:
Would you jeopardize your good practices just to suit a client? If you are staunchly in favour of XP, sell it! If they want you to use a methodology that you strongly disagree with. Tell them that. If you can't come to a consensus, there should be no deal.
Do I tell a baker what grain to use? How hot to have the ovens? Hell no. If I say I want poppy seeds on the buns I don't care how they are put there so long as they are there. Dp I select a baker based on his methods, or on how damn tasty the bread is? Letting a non programmer tell you how to do your craft is just plain bad.
If you are trying to extol the virtues of XP then be upfront, pitch the cost-benefits and ROI. Show them why it is better for them in terms of developer efficiency and defect reduction. If you are working for non-programmers, you are the expert, take the reigns and give advice.
If your team excels at XP and has great results you will have no problem selling any potential client on your practices. Results matter to clients; if you can prove that you consistently produce high quality products within consistent timelines you should have no problem selling your methodology. (with some exceptions that absolutely require waterfall).
Either clients who've already had good results on XP projects.
Or clients who've swallowed the Kool-Aid.
Which arguably makes these clients few and far between :-)
I think it probably takes less convincing than it used to for customers to accept agile development practices, particularly XP, since they are now much more mainstream. Customers who have had positive experiences with agile teams in the past are more likely to buy into these methods. It's probably easier for a smaller customer, or a customer with a smaller problem to accept XP if they have concerns about it. With a skeptical customer, I would suggest starting small and building confidence. And make sure you deliver on your promises!
Almost everyone else seems to be interpreting your question in the context that you are or work for an ISV writing custom software for a client. Is that the situation?
If your question had been something along the lines of what kind of company is likely to adopt XP, then I would say a company who has been burned in the past spending too much time writing developer documentation and designing for reuse only to have to throw it all away as a big waste of time and effort.
The customer has to accept iterative delivery with fixed time, fixed resources, fixed quality (it's working to 100%), and a slightly variable scope, per iteration.
However, it is much more usual that they want to fix time, resources, quality AND scope.
The type of client that is likely to support XP practices,
is one that already understands the benefits and drawbacks of the software production system that XP provides.