答:
I'll consider different aspects of your question separately:

Your first job is never going to be very challenging. The reason is that university is teaching you stuff you'll need in 30 years, while companies must work with technology that is already available. It's hoped the 30 year stuff is more advanced than the current state of the art. The half year timespan also causes work to be different than what you're used to in university.

Learning is pretty much done on your own time. This is unfortunate fact, but the cost of people is just so high that they must always be doing something productive. Best alternative would be if can combine learning and productive development, but then you'll be working with tech you don't know yet, and it can cause problems simply because you don't understand the tech you're using. If you want to create stuff that actually works, the learning has to be done outside of production environment. In many companies this just means it's your free time.

You should consider perl just as a challenge -- how to improve your work practices so that those will be useful not only to perl, but any new system you're going to encounter in 30 next years.

When learning new things, focus on the fundamentals. Perl has regular expressions, hash tables and many good data structures. All knowledge of how to make best use of them is useful in the future.


问:
Does JavaFX have a future?
I have not intended to hash and rehash the same matter, but just to decide, what to learn first (JavaFX, Flex, HTML5, etc.) I would pull through a kind of survey, especially as the recent similar questions here came out since at least one year.

So, what is JavaFX prospect as a RIA technology for the next couple of years?

答:
JavaFX is definitely not a mainstream technology now, but it might help you to understand how non-HTML and JS-based RIA applications work. So, if you just decide what to start learning I would suggest first trying to get acquainted with some general ideas of how implementing RIA applications and every RIA technology would do here as long as you have good materials for them.

On a long run I would favor a platform and vendor agnostic approaches, like HTML5. Nonetheless, looking to some established RIA technologies, like Flash from Macromedia/Adobe, Silverlight from MS or Google Web Toolkit is never a disadvantage -- they definitely have some brilliant ideas you might not find elsewhere.

OwnerDisplayName: Albert Galiev

ContentLicense: CC BY-SA 3.0

Title: Does JavaFX have a future?


问:
Why is Python recommended as an entry level programming language?
I've read here on P.SE more questions in which beginner programmers are advised to pick Python as their first programming language.

Don't get me wrong, I like Python. I like it a lot! But its philosophy revolves around "We are all consenting adults here".

From an experience/knowledge point of view, a beginner programmer is not an adult. Which then kinda means it is easier to shoot yourself in the foot and pick up some bad habits even if you survive the wound.

I'm thinking that in a "more static" language it would be harder to shoot yourself in the foot as it will be more restrictive.

Back to my question. Why is Python recommended as an entry level programming language?

What are the points that make it good for teaching a programming language. Or... is it personal preference of the adviser?

答:
Python is a great language for beginners because it makes simple things simple while making enough complicated things possible that it isn't be regarded as a useless toy language and even advanced programmers find it to be the right tool for some jobs.  Specifically, simple things include:

An absolute minimum of boilerplate code for simple programs.

Garbage collection.

Dynamic typing.

Clean, simple syntax.

Compare that to e.g. Java or C++ and the difficulty of explaining all the concepts involved in a "Hello, world" program.  Complicated things include:

Introspection (Python's equivalent to reflection).

Monkey patching.

The things that can be done with the huge standard library.

That said, noone who only knows Python is a good programmer because noone who only knows any one language or one style of language is a good programmer.  Anyone serious about programming should eventually learn something lower-level, just not while he/she is still trying to grok flow control, recursion and other basics.


问:
What's the current best practice for C multithreading?
I've been a Java (and PHP) developer for most of my life, but will need to use C for my next project. I remember some basic stuff we did back in school with fork, pthread, semaphores, etc. but I'm not sure if that's still the "way to go" here, or if there have been any recent developments/improvements etc.

Google's results seem to be fairly dated. Or does that just mean that this is still the current "state of the art"?

Or will I have to use a (system-independent) libary like glib if I want higher-level abstractions, like synchronized queues? What other libraries are there? (The programm will only have to run on Linux though)

答:
Well, basically it's still the same. You still got pthreads (on Linux), forking is still used in some cases. Mutexes and semaphores are also there. Of course, there is CAS available but it's not like something really new.

What we have now is a few libraries for doing some multithreaded stuff a little differently. You can use libevent2 or libev for building event systems (though they are most useful in networking, for async reading and writing from sockets). And there is ZeroMQ which you may use to avoid direct communication of threads, it's actually pretty useful, just use their ipc transport.

As for data structures there are a few libs like glib or a lib from ZMQ guys.

Be warned though, C is still C and you must be as careful with it as ever.

OwnerDisplayName: Dexter

OwnerDisplayName: jartur


问:
How useful are Lisp macros?
Common Lisp allows you to write macros that do whatever source transformation you want.

Scheme gives you a hygienic pattern-matching system that lets you perform transformations as well.  How useful are macros in practice?  Paul Graham said in Beating the Averages that:

The source code of the Viaweb editor was probably about 20-25% macros.

What sorts of things do people actually end up doing with macros?

答:
What sorts of things do people actually end up doing with macros?

Writing language extensions or DSL's.

To get a feel for this in Lisp-like languages, study Racket, which has several language variants: Typed Racket, R6RS, and Datalog.

See also the Boo language, which gives you access to the compiler pipeline for the specific purpose of creating Domain-Specific Languages through macros.

Title: How useful are Lisp macros?


答:
Here are some examples:

Scheme:

define for function definitions.  Basically it makes a shorter way to define a function.

let for creating lexically scoped variables.

Clojure:

defn, according to its docs:

Same as (def name (fn [params* ] exprs*)) or (def
    name (fn ([params* ] exprs*)+)) with any doc-string or attrs added
    to the var metadata

for:  list comprehensions

defmacro: ironic?

defmethod, defmulti:  working with multi-methods

ns

A lot of these macros make it much easier to write code at a more abstract level.  I think of macros as being similar, in many ways, to syntax in non-Lisps.

The plotting library Incanter provides macros for some complex data manipulations.

Title: How useful are Lisp macros?

Body:
Common Lisp allows you to write macros that do whatever source transformation you want.

Scheme gives you a hygienic pattern-matching system that lets you perform transformations as well.  How useful are macros in practice?  Paul Graham said in Beating the Averages that:

The source code of the Viaweb editor was probably about 20-25% macros.

What sorts of things do people actually end up doing with macros?


问:
Question about Creating a Scripting Language
Say, for example, I wanted to pay somebody to create a programming language or scripting language for me. What type of document would they need, in order to fully understand what it is exactly that I want.

I mean, are there standard documents that describe the new programming/scripting language in question?

答:
You will need the following:

A reason for creating a new language

A Philosophy

A Semantic Definition

A lexical description of your tokens

A Syntax Analysis definition

How will your language be different? What is its mission? Is it functional? Is it object orientated? Is it a meta-language? What are its unique features? What will it give the world that doesn't exist (or exists in an ugly way)? How do you want to change things? Is it compiled or interpreted? A DSL or general purpose language? This is your philosophy and dictates alot about your language's design.

Next, work on scratching out rough syntax and semantics on paper. This will be your semantic definition ... writing fake code is a great way to develop your thoughts. Read "The C Programming Language" for an excellent example of how this is done. Play with it.

You will then need to define your tokens and syntax in some way. Programs then process these into automata capable of reading in strings and processing the syntax. Yacc and Bison use Regular Expressions and a BNF style syntax for lexical and syntax analysis respectively. There are also Yacc and Bison like tools in for other languages.

You will also need a grounding in language theory/compilers to know what NOT to do. Examples include ambiguous grammars, AST generation and manipulation problems and generally how to make life simple for yourself. Knowing the theory is very important. I would consider getting the following to start off:

Compilers: Principles, Techniques and Tools (Dragon Book)

Modern Compiler Implementation in C or Modern Compiler Implementation in Java


问:
Do I really need a disclaimer for free software?
If I publish some software on my website which can be downloaded and used free of charge, do I still need a disclaimer? I mean, I am not even selling anything, there is no contract, so why should there be an implied warranty?

(Which also makes me wonder why there are disclaimers on things like the MIT license.)

Edit: I am not a US citizen, I am kind of looking for answers as general as possible and as specific as necessary.

答: Since all software is copyright protected, it is necessary to attach a license to your code. Regardless if it's free or not. People using it need to know how they can use it. It's all a matter of our (US anyway) legal system.</p>


答:
You don't HAVE TO do anything, regarding ... anything at all ... if you're giving away your application for free (public domain), waiving rights to it and everything else that entails.

If however, you still wish to hold on to some of those, you might want to attach some legal paragraph to it. Your choice ...

Title: Do I really need a disclaimer for free software?

Body:
If I publish some software on my website which can be downloaded and used free of charge, do I still need a disclaimer? I mean, I am not even selling anything, there is no contract, so why should there be an implied warranty?

(Which also makes me wonder why there are disclaimers on things like the MIT license.)

Edit: I am not a US citizen, I am kind of looking for answers as general as possible and as specific as necessary.


答: it depends on where you live and the chance of getting sued because your code had a bug, since you aren't in the U.S. there is a pretty good chance you probably don't need one, but a line that says "This code is provided as is, and no guarantee is given that this code will preform in the desired way." isn't a monumental effort.</p>


答:
I'm not sure entirely what kind of disclaimer you have in mind, but the point is typically more to protect you as a developer than to guarantee something for the users.

You basically want to explicitly state somewhere that you're providing the software "as is" and that you should not be held liable if the user misuses it or if the software malfunctions and damages the user's machine or data.

You mentioned that you're using WTFPL, and it suggests the following wording:

```<code> /* This program is free software. It comes without any warranty, to
 * the extent permitted by applicable law. You can redistribute it
 * and/or modify it under the terms of the Do What The Fuck You Want
 * To Public License, Version 2, as published by Sam Hocevar. See
 * http://sam.zoy.org/wtfpl/COPYING for more details. */
</code>```

With this notice in place, you're not offering any implied warranty.

Do you have to add a notice like this? That depends entirely on where you live, what your laws are, etc. I'm not a lawyer, but I don't see a situation where putting a notice like this in place could hurt you, so I'd add one even for free software. If you think that the app you wrote is worth the hassle, you can also consult a lawyer to make sure you as a developer are fully protected.

Body:
I'm not sure entirely what kind of disclaimer you have in mind, but the point is typically more to protect you as a developer than to guarantee something for the users.

You basically want to explicitly state somewhere that you're providing the software "as is" and that you should not be held liable if the user misuses it or if the software malfunctions and damages the user's machine or data.

You mentioned that you're using WTFPL, and it suggests the following wording:

 /* This program is free software. It comes without any warranty, to
 * the extent permitted by applicable law. You can redistribute it
 * and/or modify it under the terms of the Do What The Fuck You Want
 * To Public License, Version 2, as published by Sam Hocevar. See
 * http://sam.zoy.org/wtfpl/COPYING for more details. */

With this notice in place, you're not offering any implied warranty.

Do you have to add a notice like this? That depends entirely on where you live, what your laws are, etc. I'm not a lawyer, but I don't see a situation where putting a notice like this in place could hurt you, so I'd add one even for free software. If you think that the app you wrote is worth the hassle, you can also consult a lawyer to make sure you as a developer are fully protected.


答:
I think it is a lot like those "Swim at your own risk" signs at pools. They don't mean anything, but them might discourage someone from trying to sue you if they reasonably think you have waived your liability.

The cold hard truth is that they could sue you and possibly even win regardless of whether you have that disclaimer in there or not. You just make a stronger case if you include it all for the cost of a few lines in a readme file.


问:
How do quick & dirty programmers know they got it right?
If you ask programmers why they should write clean code, the number one answer you get is maintainability.  While that's on my list, my main reason is more immediate and less altruistic:  I can't tell if my new code is correct if it's too dirty.  I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly.  Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."  Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal?  Is it a skill worth trying to develop?  Or is a lack of confidence in the code something some people just find easier to accept?

答:
Quick and dirty is perfectly fine within a subsystem. If you have a well defined interface between your crap and the rest of the system, and a good set of unit tests that verify that you ugly quick and dirty code does the right thing, it may be perfectly fine.

For example, maybe you have some hideous hack of regular expressions and byte offsets to parse some files coming from a third party. And assume you have a test saying that the result you get out of parsing example files is what you expect. You could clean this up so that you could ... I don't know, react more quickly when a third party changes a file format? That just doesn't happen often enough. More likely they'll change to a completely new API and you'll throw away the old parser and plug in a new one that conforms to the same API, and voila, you're done.

Where quick and dirty becomes a problem is when your architecture is quick and dirty. Your core domain object need to be well thought out, and your interfaces, but the edges of your system can usually be messy without ever having to pay the piper.


答:
I can't tell if my new code is correct if it's too dirty.

"Dirty" means different things to different people. To me, it mostly means relying on things that you know you probably shouldn't rely on, but which you also know that you can expect to work in the near term. Examples: assuming that a button is 20 pixels high instead of calculating the height; hard coding an IP address instead of resolving a name; counting on an array to be sorted because you know that it is, even though the method that provides the array doesn't guarantee it.

Dirty code is fragile -- you can test it and know that it works now, but it's a pretty good bet that it'll break at some point in the future (or else force everyone to walk on eggshells for fear of breaking it).

Title: How do quick & dirty programmers know they got it right?

Body:
If you ask programmers why they should write clean code, the number one answer you get is maintainability.  While that's on my list, my main reason is more immediate and less altruistic:  I can't tell if my new code is correct if it's too dirty.  I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly.  Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."  Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal?  Is it a skill worth trying to develop?  Or is a lack of confidence in the code something some people just find easier to accept?


答:
Take a look at this posting by Matthias Felleisen to the LL1 discuss list in 2002. He suggests three main uses for macros:

Data sublanguages: I can write simple-looking expressions and
  create complex nested lists/arrays/tables with quote, unquote, etc.
  neatly dressed up with macros.

Binding constructs: I can introduce new binding constructs with
  macros. That helps me get rid of lambdas and place things
  closer together that belong together.

Evaluation reordering: I can introduce constructs that delay/postpone
  the evaluation of expressions as needed. Think of loops, new conditionals,
  delay/force, etc.
  [Note: In Haskell or any lazy language, this one is unnecessary.]

Title: How useful are Lisp macros?


答:
At the risk of sounding a little controversial, I'd argue that nobody truly KNOWS that their code is 100% correct and 100% without error. Even when you have really good test coverage and you are rigorously applying good BDD/TDD practices, you can still develop code that contains errors, and yes that can even contain side-effects!

Just writing code and assuming it works implies overconfidence on the part of the developer's sense of that developer's own abilities, and that when problems arise (which they inevitably will) the effort to debug and maintain the code will be costly, especially if another developer needs to maintain the code later on.  The real difference is made by applying good software engineering practices, which ensure that you can have real confidence that your code is likely to work most of the time, and that if you do encounter an error, it is more likely to be easier to debug and much less costly to change and maintain regardless of the person who works on that code later on.

The salient point is that well factored and well tested code will allow OTHERS to have confidence in your code, which is in most cases more important than your own confidence.


问:
What's a good way to prepare for this course titled "Programming Language Security"?
I have a course with the following description:

The purpose of this course is the study of programming language security features  and languages designed to support it explicitly. Static and dynamic constructs for security in languages and systems, as well as software engineering security principles/patterns.

Topics:

Basic Programming Language security framework.

Designing secure programming languages

Access control in programming languages

Information flow languages

Capability Languages

Mobile programming languages

Software Engineering and Security

Basic software vulnerabilities in systems

Secure Software Engineering life-cycle

Patterns, and Practices for software security

I'm confused - How is PL security different from regular security? I'm looking for possible textbooks/books to study, or websites that are good in this topic, or any advice/tips. The professor told me to know C and Java well, that's all I know so far.

I appreciate any tips or advice.

答:
The best way to prepare for the course is to buy the book ahead of time and start reading it.

I know it can be dull, but text books are actually designed to teach you the material.

If you want to get ahead, dig in and start reading.


问:
As a young developer, should I be worried about having to use "out-of-style" tech at work?
I'm a recent college graduate (last May!). While I was still in school, I wanted to make sure that I had a job before I graduated, and very early (probably too early) in my job search I settled on one in a region I'd been hoping to move to after undergrad.

However, I've been second guessing this decision for months now, for several reasons. One is that I'm not very challenged at work, and I feel like I haven't improved much at programming since starting here. I can always make time to work on open source (and have in the past) outside of my job, though, so I do have a venue to get around this disappointment. More importantly, I'm worried by the fact that my job is basically to work on a creaky old Perl web application (using Mason and a weird in-house ORM).

Am I shooting myself in the foot here by working with a technology that's no longer popular, and won't really help me out getting a job in the future? I rarely see Perl jobs, and when I do, it's usually doing something I'm not interested in (front-end web development stuff).

Systems programming, visualisation, network programming, or at least backend web development stuff are the sort of topics that I'd actually enjoy working in -- it doesn't seem like my current work experience is helping me towards positions doing any of these things.

答:
Somebody has to pickup the trash, clean the toilets, dig ditches and work at McDonalds. Right now you are doing the software development version of that.

There is NOTHING wrong with recognizing that and aspiring to something greater!

What you do now definitely shapes what you do tomorrow, next year and the next ten years!

Anyone else that says different is trying to keep you down or make themselves feel better for being in the same depressing place!

As for Perl, it is out of style in "Career" sense of the word. As in unless you want to make a career as being the Perl guy, start learning something newer and more en-vogue. Python, Java, C# will open more doors and be more marketable or something that is on the cusp of hitting it big in a few more years like Erlang.

All that said, *learning how not to do** is just as valuable as how to do, and learning from others mistakes is less painful than learning from your own.

Right now you are getting a lessons in both of those things.


问:
In agile environment, how is bug tracking and iteration tracking consolidated.
This topic stemmed from my other question about management-imposed waterfall-like schedule. From the responses in the other thread, I gathered this much about what is generally advised:

Each story should be completed with no bugs.  Story is not closed until all bugs have been addressed.  No news there and I think we can all agree with this.

If at a later date QA (or worse yet a customer) finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work.

Does this sum up general handling of bugs in agile environment?

If yes, the part I'm curious about is how do teams handle tracking in two different systems? (unless most teams don't have different systems).

I've read a lot of advice (including Joel's blog) on software development in general and specifically on importance of a good bug tracking tool. At the same time when you read books on agile methodology, none of them seem to cover this topic because in "pure" agile, you finish iteration with no bugs. Feels like there's a hole there somewhere.

So how do real teams operate? To track iterations you'd use (whiteboard, Rally...), to track bugs you'd use something from another set of products (if you are lucky enough, you might even get stuck with HP Quality Center).  Should there be 2 separate systems? If they are separate, do teams spend time creating import/sync functionality between them? What have you done in your company? Is bug tracking software even used? Or do you just go straight to creating a story?

答:
"...finds a bug, the report goes into a bug tracking database and also becomes a story which should be prioritized just like all other work.

The question is, should bug tracking and feature tracking be different, and can you use a single system to do both as well as schedule iterations/milestones/etc...

In terms of a "pure" Agile approach, you allow your team to use any combination of tools and processes that works well for them.  Sure, you may find a single product that does everything, but perhaps it doesn't do some things as well as you'd like. If you run multiple systems, you need to determine just how integrated they need to be, and if any integration is needed, find the means to do it, and decide just how much information needs to be duplicated. It all boils down to a cost/benefit situation, so naturally any system employed needs to take into account the impact on a team's overall efficiency.

Where I work, we use a Redmine system to track bugs and features in a single system for multiple projects, with links between each project where dependencies exist.  We create labels that relate to milestones, which for us are effectively long iterations that may range anywhere from a matter of weeks to a matter of months.  For individual tasks and features, we tend not to track iterations too closely, so we have no need to worry about burn-down charts, white boards, sticky notes, feature cards and all of that stuff, as we've found that for our specific needs, some of this stuff is overkill.  Each feature itself effectively represents small iterations of between 2-10 days duration, and for those that might care, we log our estimates of time versus actual time for later analysis.  This may sound a little ad-hoc, but works for us and ultimately our real measure is working code within a series of time frames.

I suppose if we decided to employ another more formally "regimented" methodology, we might consider a tool to aid in tracking progress, but with what we currently have invested in our present method, we'd probably feed at a minimum the short feature descriptions and time data to another system, unless someone has developed a module for Redmine that does what we want it to, or if it became really important to us, we might create the Redmine module ourselves to avoid any nasty integration headaches that might concern us.


答:
Look for opportunities to build and maintain experience in other languages, while showing that you are a dedicated employee who can rise to the challenge. Drive yourself to maintain a steady work output of the highest quality you can achieve, and use any slack time to either take on more work, or if allowed to create things that will allow you to develop skills and knowledge in other areas.  Even a simple demo that solves a real business problem in a different way (with a more en-vogue language) will allow you to improve skills, and show your boss that you are actively thinking outside the box. Just be careful to avoid being seen as shirking your other duties simply to work on side-projects.

Dedication is the key.  Grads aren't expected to have years of experience in lots of languages.  You can always spend a year developing essential communication skills, and showing that you can step up to the challenge, even if the challenge is to look beyond the stuff you feel is "boring". Learn how to up-sell your skills when it comes time to move on.  You are expected to continue learning on the job, and to show the next employer that you are actively seeking to improve skills.

Remember, nobody likes to employ a "know-it-all".  I've always looked to hire people - even for senior positions - who want to learn and grow further.

Title: As a young developer, should I be worried about having to use "out-of-style" tech at work?

Body:
I'm a recent college graduate (last May!). While I was still in school, I wanted to make sure that I had a job before I graduated, and very early (probably too early) in my job search I settled on one in a region I'd been hoping to move to after undergrad.

However, I've been second guessing this decision for months now, for several reasons. One is that I'm not very challenged at work, and I feel like I haven't improved much at programming since starting here. I can always make time to work on open source (and have in the past) outside of my job, though, so I do have a venue to get around this disappointment. More importantly, I'm worried by the fact that my job is basically to work on a creaky old Perl web application (using Mason and a weird in-house ORM).

Am I shooting myself in the foot here by working with a technology that's no longer popular, and won't really help me out getting a job in the future? I rarely see Perl jobs, and when I do, it's usually doing something I'm not interested in (front-end web development stuff).

Systems programming, visualisation, network programming, or at least backend web development stuff are the sort of topics that I'd actually enjoy working in -- it doesn't seem like my current work experience is helping me towards positions doing any of these things.


问:
Is there a formal anti-pattern to describe the scenario?
Some code is written to generate Excel Spreadsheets (Office Interop).

The code performs very poorly.

A subsystem is designed to generate the files at night. Performance isn't a concern at night.

A function is created to pick the correct file from the 100 different files available depending on a chosen set of parameters.

Because physical files exist, an archival system is added to backup these files (There is no reason to archive.  These files should be generated on the fly).

This system doesn't include a configuration file, instead it has a hard coded "server picker" function that simply reflects upon the server the code is running upon.

A scheduled task is necessary to support and run this service.

This boils down to a single problem.  The original code performs far too poorly to run in a production environment.

Had the performance problem been resolved, the subsystem and subsequently archiving system, "file picker factory function", hard coded failure point and the maintenance of the scheduled task and its added point of failure have no need to exist.

This is a "cascading failure" if you will.  The original problem led to more bad code, more bad solutions and unnecessary overhead.  Is there a formal anti-pattern or general term to describe it?

答:
Not certain if this helps, but office automation is often a special case:

Office automation is usually done this way if it must be automated off a user desktop (esp. for .net websites because the office automation docs correctly warn you that there will be bad leaks in office interop tools if they are run headless.  When I was forced to write headless processes to generate office docs with that toolkit we called the sacrificial services because you had to murder them periodically to get the memory back.

Other than the archiving what you are describing is unfortunately a best practice in some cases.

Link: http://support.microsoft.com/kb/257757


答:
First jobs in the software industry are often crappy jobs.  While learning some programming skills will happen, the more important education that you're receiving is how to work in a company.

Showing up on a regular schedule, working 8+ hour days, using source control software, dealing with bosses & co-workers, getting that 3am call because the production server has gone down and it needs fixing... those are the skills you're learning from your first job.

That being said, if you're bored and not enjoying what you do, quit.  If you feel this job won't help you get into your eventual career goal, quit.  There's plenty of jobs out there for talented people.


问:
Software Defect Patterns
Does the Pareto Principle, that being 20% of the causes are link to 80% of the problems, apply to software bugs, and if so, are there any common patterns of note on average within the 20% of cause?  </p>

答:
Sure, there are plenty of patterns where bugs can emerge. These are a couple of categories I have encountered in my career, but I'm sure there are many others.

Lack of Ownership -> Code Atrophy

If there is module, tool, or library that nobody is responsible for then it will quickly become a bug-farm. If a piece of code has a clear owner, then somebody is on the hook for the code's clarity and overall maintenance. However, if code is allowed to rot then many local-fixes will end up introducing subtle behaviors that will break future clients.

Poor Architecture -> Ignored Requirements

Another pattern which causes bugs to crop up is poor architecture, specifically tight coupling. Poor architecture leads to tightly coupled components that have an unofficial contract between one another. For example, initialize needs to happen in a certain order. This leads to implicit requirements for using code.

A hypothetical example would be: you create a new Servlet for exposing a new webpage. However, that servlet will crash in production. The reason for this is that servlets will work correctly when exposed from http://localhost/ however, in prod they need to be registered with the ServletAuthorizationManager or some other hidden constraint.

Title: Software Defect Patterns


问:
Is it legal or ethical for me to use my previous employer's code in a new project?
I participated and wrote a large amount of code in a project which my current company outsourcing to my former company last year.

After that I left my former company and recently join in my current company. Several days ago, my current employer asks me to continue the project on top of the existing code (my current company owns the copyright and they have the code).

I think it is neither ethical nor legal to do this. So should I refuse my current employer? Could my former employer take me to court if I undertake the project?

答: None of us here are lawyers, and we don't know what jurisdictions you and the companies are in (although I'd hazard a guess privately), so any legal answer is probably wrong.  But there's a point you haven't brought out - what was YOUR contractual relationship with the company that performed the original work?  You may actually be contractually enjoined from using what you know about that work for your new employer.  Strange as that sounds, here in the USA, it's not only possible, at some high levels in companies, it is the key question (where the "Doctrine of Inevitable Disclosure" tends to be invoked).</p>


问:
What is ethical/unethical while seeking help on the web with programming assignments?
I have used the web and Stack Overflow extensively during the past month or so in creating my final project for my C# class. I have used so much code that I didn't write myself that I feel I am being unethical by not giving proper credit to the people who helped me; or the websites that have provided excellent examples.

Is it unethical to publish work which was created by me, even though its hardest problems were solved by other people? Should I credit these people for helping me with my assignment? Or the web sites which provided examples?

答:
Yes, it's unethical.  You write:

I have used so much code that I didn't write myself that I feel I am being unethical by not giving proper credit to the people who helped me;

It's your final project.  Not the web's.  Not Steve McConnell's.  If you're submitting code you didn't write, that's plagiarism, and any decent instructor who caught you would at least give you a zero, if not drop you from the course.

Put differently, if you submitted a final paper to your English Composition class composed largely of paragraphs you copied from Hemingway, Shakespeare, Thoreau, and the Encyclopedia Britannica, you'd deserve the same fate.


问:
Power failure should be considered as a scenario to implement?
Do you think that power failure is a scenario to implement?

At what time that scenario should be taken into consideration? If power failure will cause some data loss so do you care about it ? if(IsImportant(data)) ... else .. ?

What do you think If our application doesn't work anymore even power failure scenario shouldn't  be fault to consider if power failure broke the application permanently ? So we have to consider these situations always ?

Can you suggest pragmatic approaches for power failure scenarios ?

答:
This entirely depends on what you are writing and who you are writing it for

I have worked on things where this is not only required, but part of the default requirements list for ALL projects, I have worked places where they don't care at all, and I have worked places that the consider that purely an infrastructure issue and not an issue for developers as many of the other answers imply.

If you are working on something that must have absolute transactional integrity under any circumstances it generally involves the developers to some degree because there are going to be some choices that are forced to make certain that things are committed to disk rather than written to buffer for example.

Andy points out the most interesting case where odd failures can be used to circumvent a security or audit policy.  I have worked on a few systems that actually worried about this sort of thing as well.

Usually you get one of the following answers for this questions:

doesn't matter, just try to make it easy to restart clean (think of paint)

it matters a little, don't corrupt anything historical, but if you loose some data since the last disk commit or transaction log backup you are probably ok (think of visual studio)

it matters quite a bit, make certain that you commit every record to disk, and probably to a log before moving to the next step, also get some decent UPSs and maybe a generator (think of financial transactions)

it is the only thing that matters more than functionality, add functionality that locks the system in a fail-safe or fail-secure mode at the first sign of disruption, buy even more/bigger UPS & generator, get a collocation site, use BGP, get a D/R site etc. etc. etc. (think security systems, banking backends, etc)

The step from the 3rd to the 4th tier is a HUGE step in many systems, but the simplest example I can think of is in a physical access security system:  If the power is out, and your UPS is down to it's last 30% your code needs to decide which doors to lock completely, which doors to unlock completely and where to unload the elevators before the power fails completely.


问:
How assertive should I be in handling exceptions in objects?
I have been writing in C# 4.0 a lot lately and trying to write as lean as possible. As such, I have not been using the classic try/catch blocks and using statements as often.

I understand the general function of .Net's garbage collection and exception handling - I want to bulletproof my code and be efficient with objects, but I am trying to achieve this with the minimum amount of 'extra code' (since 'bloat' pissed people off).

And to be clear, I understand using() is fundamental for relinquishing resources to handles and other code and its relationship to the IDisposable interface.

But I am trying to get a better grip about how assertive a programmer should be in exception handling objects.

Are there key places in code you'd say try/catch blocks and/or using statements are inarguably necessary? Within the contexts of garbage collection and exception handling, what common-use objects/scenarios would you recommend explicit attention?

Should you simply make a catch block for every possible exception an object might through? How deep should they be nested? Are there steps I can take to proactively collect garbage (for example, to combat the example in comments of waiting for Dispose() to be called)?

答:
Every exception gets handled.  You just get to choose if it kills your program or not, and if not, what you want to do after that.  I regularly write code that throws exceptions all up and down the stack, catches the ones that it wants to recover from, and has a simple main method:</p>

```<code>public static int main(string args[])
{
    try {
        DoSomethingUseful(args);
        return 0;
    } catch (Exception e) {
        Console.Write("Uncaught exception percolated to top level: " + e);
    }
    return 1;
}
</code>```

Body:
Every exception gets handled.  You just get to choose if it kills your program or not, and if not, what you want to do after that.  I regularly write code that throws exceptions all up and down the stack, catches the ones that it wants to recover from, and has a simple main method:

public static int main(string args[])
{
    try {
        DoSomethingUseful(args);
        return 0;
    } catch (Exception e) {
        Console.Write("Uncaught exception percolated to top level: " + e);
    }
    return 1;
}


答:
Loss of power implies that by default your software will stop working.  You have a couple of choices, either accept that data loss is likely, or code your software so that data loss cannot occur.

If you assume that you need to preserve data at all times, you are still likely to encounter the possibility that some data loss may still occur.  For example, your code begins a write operation (eg: to database, file, etc...), and before the operation completes, the power is lost.  Nothing you can do without ensuring the hardware has some means to signal your software to indicate that power will fail, and to then provide enough time for your software to commit any changes to some sort of storage. The other option would be to cache all volatile changes to a data store every time something changes. This may have an impact on your program performance, which probably also needs to be taken into account. IMHO however, this is a bit of an overkill scenario, but do-able if absolutely required.

Ultimately you need to look to your requirements, and to your product design. You really should get feedback from the customer about such requirements also.  If near 100% data retention is essential, then design your product to suit, and if not, I wouldn't really worry about it.

Title: Power failure should be considered as a scenario to implement?

Body:
Do you think that power failure is a scenario to implement?

At what time that scenario should be taken into consideration? If power failure will cause some data loss so do you care about it ? if(IsImportant(data)) ... else .. ?

What do you think If our application doesn't work anymore even power failure scenario shouldn't  be fault to consider if power failure broke the application permanently ? So we have to consider these situations always ?

Can you suggest pragmatic approaches for power failure scenarios ?


问:
Is there a canonical book on Scala?
I'm interested in learning Scala, but due to is relative newness, I can't seem to find a whole lot of books about it.

Is there a book out there that's the de-facto standard for describing best practices, design methodologies, and other helpful information on Scala? What makes that book special?

答:
Artima's Programming in Scala is the best Scala book you can get at the moment. Very recommended. I found O'Reilly's Programming Scala to be a good second book; It moves a bit faster than I'd like though.

I also tried David Pollak's Beginning Scala but didn't quite like it, and I don't recommend it to anyone.

All the above-mentioned books are somewhat oudated as they don't cover a lot of things new in Scala 2.8. I am hoping that the updated editions of these books will be published soon.

Though more than half a dozen Scala books have already been published, I believe that the best books are yet to come.

The two books in particular that I think you should keep your eye on are:

Scala in Depth by Josh Suereth

Steps in Scala by Christos Loverdos and Apostolos Syropoulos

Title: Is there a canonical book on Scala?

ContentLicense: CC BY-SA 2.5


问:
What's better approach when creating a user control: receive a full object or only the needed values?
I'm working with ASP.NET Web User Control (WUC) and I got to this question:

I'm creating a WUC to show an object's data. This object is already loaded when I call that WUC. I'm wondering what would be better: give the WUC the full object or only the necessary attributes?

答:
If the UC is responsible for displaying the entire object, and only that object (not other objects) then it should be passed an instance of it, or a base class/interface of it.

If the UC is meant to be more general, though, or only displays a couple properties, you might just expose members for those specific properties.

OwnerDisplayName: Andrew Barber


答: Pass the full object, as long as the user control should "know of" its existence (separation of concerns). If the class for the object ever changes, you will only need to modify the user control internally, not how it is invoked.</p>

Title: What's better approach when creating a user control: receive a full object or only the needed values?

Body:
I'm working with ASP.NET Web User Control (WUC) and I got to this question:

I'm creating a WUC to show an object's data. This object is already loaded when I call that WUC. I'm wondering what would be better: give the WUC the full object or only the necessary attributes?

OwnerDisplayName: arknotts


答:
Every system provides its own model of interactions and its own set of invariants. A programming language is an opportunity to provide a security model different from the host (OS) model, either finer-grained or just suited to a different (more specialized) purpose.

For example, the OS security model is typically organized around users/roles/groups and the resources (files, sockets, syscalls) that each is allowed access to. The JavaScript-in-a-browser security model, on the other hand, is concerned with source domains, JS code, and DOM objects. From the OS perspective, a browser is just a program run by a single user who presumably has permission to access the whole reachable internet and access all of the user's files. From the JS perspective, however, your favorite adorable-kitten server had better not be able to read your online banking pages or credentials.

So, PL security has a broader range of goals, resulting in different kinds of security models and different techniques for enforcing them.

Title: What's a good way to prepare for this course titled "Programming Language Security"?

Body:
I have a course with the following description:

The purpose of this course is the study of programming language security features  and languages designed to support it explicitly. Static and dynamic constructs for security in languages and systems, as well as software engineering security principles/patterns.

Topics:

Basic Programming Language security framework.

Designing secure programming languages

Access control in programming languages

Information flow languages

Capability Languages

Mobile programming languages

Software Engineering and Security

Basic software vulnerabilities in systems

Secure Software Engineering life-cycle

Patterns, and Practices for software security

I'm confused - How is PL security different from regular security? I'm looking for possible textbooks/books to study, or websites that are good in this topic, or any advice/tips. The professor told me to know C and Java well, that's all I know so far.

I appreciate any tips or advice.


答:
Lack of vision : know who the actual end user will be

A surprisingly pattern I have seen emerge in some larger corporation though I feel it can also effect smaller teams too (large corporation here means more a self perceived state of mind of said corporation than it's measurable size).

The fact that system designers and architects do not see the whole picture of how the software is truly utilized.  This creates systemic software where some parts of the system is completely ignored in the specs.  For example cutting out the people who will configure it for the customers by thinking and designing the system to be configured by the customers themselves.  Reality however makes that the system is very complex to configure and install, so much that the training required to perform the job can takes months.  Yet persistently they refuse to invest in tools to help mass configuring making the whole process a laborious manual operation.

This runs deeper than lack of tools, documentation, because it is believed to be targeted to end users goes through a long process of revision and styling and great effort is placed in vulgarization.  The end result is a document that is still too complex for the end user to use yet because of the lengthy process in creating this doc it is out of date and incomplete making it also useless for the people configuring the system.

This is just an example but it applies to implementation teams, support teams, trainers and many others that, although do not directly participate in the creation of the software, are still an integral part of the system the software is to service.

In short if you build a system for a doctor, it is not necessarily him that will operate ALL the aspects of the software.

Title: Software Defect Patterns

Body: Does the Pareto Principle, that being 20% of the causes are link to 80% of the problems, apply to software bugs, and if so, are there any common patterns of note on average within the 20% of cause?  </p>


答:
Most controls will do just fine with the object itself.  If you want to shield yourself a bit,  create an interface which the object inherits, then pass the object as that interface to the UC.  That way, you can change replace the object later and the UC won't care, because it only knows about the pieces in the interface.

You really don't want to pass individual properties unless it's only 1 or 2.  Otherwise, you end up with functions that have a large number of parameters, or long lists of object initialization lines.  Pass an object or an interface - things will be much cleaner.


问:
Why are SQL databases still used with ORM?
ORMs and persistence ignorance make perfect sense: if I am programming in a language, then I want to use the language's native implementation of objects and data structures to drive my program. I shouldn't need to worry about SQL or a database, and I always thought that inline SQL strings in a program was very cumbersome.

Why is SQL still used as a backend? Why doesn't the ORM just persist objects to XML or a binary file(s) and avoid all the overheads and difficulties of administering a database server?

答:
Why are 'we' keeping them?  I cant speak for you, but I need to do more with data than simply load and save isolated objects.  XML files arent going to do me much good if there's no way to search them and perform calculations against the data they contain other than to sequencially open each one.  How do you calculate a breakdown of, say, this years sales by month and product, if all your data is spread across millions of little xml files?

And, quite frankly, if you think managing a database server is difficult, by comparison, trying to track millions of files in the file system is a lot more complex!


答:
You've touched on something that the NoSQL movement is based upon, that most systems (particularly simple web applications) are usually interested in just serializing out their content model objects to a key/value store, and that a lot of data scenarios can sacrifice duplication of data for performance/simplification gains with simple indexing. This does not mean SQL databases (and the ORM to talk to them) are going away at all however. There is still a great need for relational data and reporting on that data, of which NoSQL is not an appropriate solution for.

I'd encourage you to check out the following:

Wikipedia: NoSQL

Wikipedia: Eventual Consistency

Is the Relational Database Doomed?

Couch DB

Mongo DB

Raven DB

Title: Why are SQL databases still used with ORM?

Body:
ORMs and persistence ignorance make perfect sense: if I am programming in a language, then I want to use the language's native implementation of objects and data structures to drive my program. I shouldn't need to worry about SQL or a database, and I always thought that inline SQL strings in a program was very cumbersome.

Why is SQL still used as a backend? Why doesn't the ORM just persist objects to XML or a binary file(s) and avoid all the overheads and difficulties of administering a database server?


问:
Ways of marking changes being made to a file
I am looking for a lightweight way to notate changes made to a file. The obvious answer to this is a version control system. But this is more robust than necessary for what I would like to do. All I want is the functionality to compare an edited file to its original in a lightweight manner.</p>

答: I just use notepad++. It has an on-the-fly style diff feature -- no versioning system required, and software is very lightweight.</p>


问:
Why do PHP variables need to be preceded with a dollar sign?
I understand that all PHP variables need to be preceded by a dollar sign (e.g. $someValue = 1), but why is this the case?  Why was this design choice made?

The reason I ask is my girlfriend asked why when I mentioned that PHP variables need to begin with a dollar sign, and I realized I had no idea why this syntactic choice was made.

Any ideas?

答:
Well I'm really not a big fan of the $$$ either (I don't really care how much the variable costed). But it comes from perl.

Interpreted scripting languages like perl or php use the $ to quickly identify and parse out variables. It's just an optimization for the interpreter. But definitely not an optimization for the programmer!


问:
Tabs versus spaces—what is the proper indentation character for everything, in every situation, ever?
The coding standards for the code hosted in drupal.org suggest to use two spaces to indent the code; other sites suggest to use tabs to indent the code.

What is the proper indentation character for everything, and in every situation? Please explain the answer you give.

答:
I. absolutely. hate. 4. spaces.

Why? Mainly because I'm tired of navigating my code with a keyboard and having to constantly hit left left left left to go over one indentation. This was born out of early versions of Notepad++ and even plain Windows notepad where there was no such thing as a format button. I had so many issues when people would only use 3 when I had used 4 everywhere else among other things.

The other reason is that the tab character exist specifically for indentation, and was only later adopted for navigation. Why are we doing space space space space when a simple tab would work? Why should IDE's have to deal with 2-5 spaced code and format correctly when a simple tab and a preference option would work?

Unfortunately I'm the minority.


答:
For simplistic systems, with very basic data storage needs, I've often gone with a custom data layer which persisted to XML.  However, to answer your question properly, we'll have to look at it from the perspective of most large companies.

Why are we even keeping SQL and a SQL database as the back-end?

One of the best answers that I can give you is that databases tend to outlive the systems that use them by far.  Business data has meaning long after the front-end's technology has become obsolete.  Refactoring or rewriting code (a task not taken lightly when it comes to large systems) is far easier than refactoring or redesigning a database.  It's more than just not having the necessary tools and techniques (TDD / automated refactoring, etc), when you are working with existing data, there are many other factors to consider, such as downtime (changing things around in a 20TB DB takes a while).

Also - SQL, is a very good 4GL for accessing data.  It abstracts away a lot of the complexity, and still allows for excellent performance (when things are done correctly).

Why doesn't the ORM just persist objects to XML or a binary file(s)? Why bother with all the overheads and difficulties of administering a database server?

If you think about what you are saying for a minute, you will realise that you are describing a database server all over again.  The actual storage mechanism databases use is a highly optimised binary file.  If you didn't use a DB server, you'd end up reinventing indexes, and then reinventing atomic transactions.  Also, if you think administering a DB is a pain, you probably haven't tried to administrate millions of disparate XML files.

Is this the way of the future?

The DB world is certainly going to change a lot in the next few years, with "NoSQL" showing many benefits.  The need for a mature, reliable way to store, retrieve and manipulate data isn't going anywhere though.


答: A little while ago there was a similar question and someone posted this link, which I found quite interesting. Personally, I've used straight SQL as well as few ORMs and in my first job I've also spent quite some time optimizing SQL queries because what appears simple seems to always break when you start working with 1M+ rows.  Although, I like working with ORM s and believe they have their place, I find myself sharing a lot of views with the author of that post.</p>


问:
How to deal with asynchronous functions when you really just want things synchronized
I am fairly new to NodeJS and I'm having a hard time wrapping my head around the asynchronous nature of functions when I really want one call to follow the other in a synchronized way.

Say for instance I am calling web service methods. Every method has a callback function. But what if I want to call 10 of them in a specific sequence? Do I really need to chain / embed all the functions in the first callback? What if the second time the chain is slightly different?

Are there any elegant patterns to deal with situations where you actually do want things to be synchronous?

Or should I really let go of this kind of programming get used to a different way of thinking? If that's true maybe someone can point me to a clean example of a longer chain of functions using callbacks...

答:
People usually use Step or Async for that. Check them out, there are a lot of nice tutorials about them, you'll see they come "to the resque:"

http://dailyjs.com/2011/11/14/popular-control-flow/

http://dailyjs.com/2011/11/07/code-review/

http://howtonode.org/step-of-conductor

Also check these 2 answers:

https://stackoverflow.com/questions/6954588/what-is-the-best-control-flow-module-for-node-js

https://stackoverflow.com/questions/5265743/node-js-what-techniques-are-there-for-writing-clean-simple-callback-code

OwnerDisplayName: alessioalex


问:
In a "Revisional Data Model," where does code that preserves a previous record's state belong?
When I say "Revisional Data Model", I mean a data model where information is never lost: Deletes never destroy any rows, and updates always cause an insert somewhere else to preserve a row's previous state before the update.

There are a few I've read about, and heard from colleagues:

Triggers in the database. The main reason why I don't like this approach is because if you depend on triggers to enforce revision integrity, the application becomes tied to the database server. If using an ORM with different providers (Oracle, MySQL, T-SQL, etc), you may need to alter some SQL to switch between them.

Human-readable trace logs. Last year I played Business Analyst for a project with a new developer because one of our sister departments was slammed with important deadlines.  She insisted that, despite the requirements I gathered and the schemas I modeled, she would insert a stored procedure to be executed with each create/update/delete statement. This sproc would just write out the old data as a formatted string, and save it to a ERRORS_LOG table in the database. Her goal was to help her with debugging the application in case anything went wrong: she wanted a trace.

Creating sister tables. This approach is like having 2 databases living in the same context. For the table Person there would be a PersonHistory table, for Product there would be ProductHistory, and so on. The schemas would be identical, and each time a change happened in the entity table, the previous state would be inserted into ProductHistory.

If you have an application where you want to allow users to "undelete" or "restore previous version" of an entity, only #3 seems like a workable solution. However, since each pair (entity and its history) have the same model/schema, they can in fact be combined. By adding bool/bit properties like IsCurrentVersion and IsDeleted, you can slice a single entity set into different states within the WHERE clause. Consider this example #4.

One disadvantage of #4 is that the database tables become hard to read when you select all rows. Mining data from a db server ide would require pretty extensive use of views, which causes the same problem as in option #1. Looking at all of the different states together in the same table makes it much more difficult to read. With approach #3, you need to look in a different table to find previous versions & deletes.

We've been using approach #4 with success. We have a RevisableEntity supertype with properties that indicate when data was changed, who changed it, whether it was deleted, archived, or modified. Updates occur on rows just as they would under normal circumstances. However as part of the same action, a corresponding insert is made into the same table / entity set. The insert contains the same values as the update before it was updated. The updated row, in addition to whatever changes were made by the user, also updates the when and who properties.

Now for my question: Where does this code belong? In the domain, or in the repository implementation? There are certain aspects of this that are storage dependent, which hint at putting the code where your ORM coupling is. However there are other aspects that the domain / application layers should be able to trust. Maybe the domain entities should manage their own revisional integrity, or maybe there should be a factory to coordinate?

答:
Let the database handle it all and store the history off in a different table.  </p>

<p>The database is good at handling data and keeping it accessible and clean, use those strengths!  Don't over complicate things to give the application extra control or extra flexibility unless you absolutely MUST have it.  Also, don't store a ton of history in your live tables unless you don't like speedy results, dump it off somewhere where else so you can better optimize speed and costs. </p>

Body:
Let the database handle it all and store the history off in a different table.

The database is good at handling data and keeping it accessible and clean, use those strengths!  Don't over complicate things to give the application extra control or extra flexibility unless you absolutely MUST have it.  Also, don't store a ton of history in your live tables unless you don't like speedy results, dump it off somewhere where else so you can better optimize speed and costs.


问:
Is code commonly generated from UML?
So when I was at university I was educated on the benefits of UML and its future in code development.

But from my industry experience, I've found that while we do use diagrams—ranging from ER diagrams, class diagrams, state diagrams, to work flow diagrams—all of it is for communication purposes.

That is, I've never generated code automatically from diagrams, and from a communication standpoint, I generally try to keep my diagrams as simple and easy to understand as possible.

But when I look at Visio and Enterprise Architect, it seems they have many different types of graphs, shapes, properties objects, most of which I don't use.

Do people use UML to do more sophisicated things such as code or database generation?

答:
While it's certainly possible to generate code (and even entire systems) straight from UML models, I've never encountered it being used in this way.

In my experience, most companies seem to use it as a communication tool for requirements, or "MS Paint for drawing diagrams".

One important distinction that I would like to make is that most UML modeling tools allow you to build up a single model of your system.  Visio, for example, has a fairly good understanding of how UML works, and there are many things you can add that are not directly diagram-related.  The actual diagrams are simply different perspectives on parts of the model, allowing you to highlight different aspects of the system.

Title: Is code commonly generated from UML?


问:
What's a good way to prepare for this course titled "Programming Language Security"?
I have a course with the following description:

The purpose of this course is the study of programming language security features  and languages designed to support it explicitly. Static and dynamic constructs for security in languages and systems, as well as software engineering security principles/patterns.

Topics:

Basic Programming Language security framework.

Designing secure programming languages

Access control in programming languages

Information flow languages

Capability Languages

Mobile programming languages

Software Engineering and Security

Basic software vulnerabilities in systems

Secure Software Engineering life-cycle

Patterns, and Practices for software security

I'm confused - How is PL security different from regular security? I'm looking for possible textbooks/books to study, or websites that are good in this topic, or any advice/tips. The professor told me to know C and Java well, that's all I know so far.

I appreciate any tips or advice.

答: I'd look up information pertaining to the idea of "state" in programming languages as well as parsing inputs and the mechanics of memory. A good many security breaches occur due to uncertain state, unsafely parsed inputs or memory overflow errors. The IT security Stack-Exchange might be a good place to poke around as well. That said, reading the book for the course is a good option as well as Richard points out. </p>


答:
The answer presented here is a quick answer and is not comprehensive, since the subject is rather big. Your question is about 3 things (at least):

1- Databases

2- SQL

3- ORM Concept

A database is any repository of data. You can store your data wherever is appropriate for your application. SQL is a way to access this data when the data usually, SQL is used to access and manipulate RDBMS. ORM represents a way to access data from within applications using SQL or other means.

My question is: why are we even keeping SQL...

If your database is not a relational database or does not beinfit from what relational database systems, you may not have to use SQL. In the past 50+ years relational database have answered so many business needs and it has grown to be robust, efficient and reliable. The conceptual strength has kept this system alive. It has been used in almost all types of applications with great success due to its ability to represent business-related transactional data needs efficiently. Developers have proved that the concept is possible to digest and grown up accustomed to this standard specifically for procedural programming. As a result of this history, relational database systems are where most enterprise data ends up to be. If you are building an application that does not need to integrate with this data, feel free to use a different database model.

Why doesn't the ORM just persist objects to XML or a binary file(s)?

This may work for small databases when concurrent access to data is not required or rare. A relational database allows concurrent access to data, locking, indexing (for fast search), as well as many other features that are not readily supported by OS file system be it XML or other. Take your bank's customer accounts database. If you go to withdraw $20 dollars, the system will need to search for your account quickly and find it among 4 million accounts. If you try to do this sequentially with a file, you will need to read about ((4 million+1)/2) records before you find a match - This is a lot of reads. Also, to update your account after you have done the withdrawal, you will have to write back the entire 4 million rows. Imagine this happening for every customer, then imagine this happening on 300 teller machines at the same time.

The following may be useful reads:

1-Relational Database Components

2-Benefits of Relational Data Model (see the bottom of the page)

ContentLicense: CC BY-SA 4.0


问:
Does not testing internals entail diligent refactoring and/or rely on developer talent?
I'm not asking here what the arguments are for/against testing
internal methods (though I'll restate some, and don't mind hearing
others). My questions relate to the implications of only testing
public interface.  Especially, whether I understand the extent of the
"refactor" part of Red-Green-Refactor in by-the-book TDD, and if there
are non TDD techniques TDD practitioners use that address the problems
that make me want to test internals.

My question is: If you write the most straightforward code possible to
get the light green, and if you don't test internal methods, does it
follow that from time to time you allow yourself to start off by
writing a class that does far more than it should with a bunch of
member variables you know will not survive refactoring?  And wind up
after refactoring with a bunch of methods that aren't explicitly
tested?

As I get familiar with TDD, it feels like anyone would at least be tempted to
test internal methods.  And many practitioners flatly say you shouldn't.
E.g. (of about 23 million results):

Item 2 here and it's comments and this StackOverflow post

Given an implementation will involve more than one non-trivial
problem, if you only test the public interface, there are two
possibilities: 1) non-trivial logic winds up getting tested only
indirectly, AND tested in the same calls as other non trivial logic.  2) you make methods
public that you don't expect clients other than the SUT and the tests
to call.  I think what I hear from the advocates of by-the-book TDD is
"1 is right.  Yes, a lot of non trivial code is tested only
indirectly, and that isn't a problem.  After all, you don't want your
tests to start failing when you improve the implementation.  Even if
they don't fail, it's not innocuous if tests keep passing when they're
targetting a bunch of no-longer-used code, because the tests show how
to use your class. You Should Only Test the Public Interface."  And
that sounds like a reasonable thing to say, but I haven't seen it said
explicitly.

But even though it sounds reasonable -- if I don't test internals I
feel like I lose part of what helps keep the tests DRIVING the coding
(maybe part of my difficulty applying the precepts is that I don't
distinguish between coding and developing).  If there's some internal
logic that has to turn a String to a valid int32, int64 or decimal
value depending on what's in the string and the type of some other
object, I want to test that little bit of logic, not just find out
that the whole method failed.  I want one test to pinpoint those few
lines of code and exercise what should fail.

The thinking in the doubly downvoted answer here seems so obviously attractive that I have to wonder if the
by-the-book fellows are neglecting to mention some
instrumentation/tracing/logging code they use in addition to TDD, or
if they watch it work in a symbolic debugger.  Or do they just
recognize that as a failure point and write a test with input that
will cause a failure pinpointing those few lines of code?  If they do
that it's testing the implementation though.  It seems so natural to
want to test that code in isolation, and verify it fails where it
should, even though it's an implementation detail.

I suppose that with talent and experience you can classify bigger chunks
of code as "non-trivial" but I haven't seen anyone bluntly saying or condescendingly implying that
that's why they don't have to test implementation details.

Lots of time it makes perfect sense to me to test the public
interface, lots of methods really are like what you see in TDD
examples.  But for the feel of where I wonder if purists are doing
something more than writing tests on a public member: Say you want to
put data from an ISAM file into a database.  There is one public
method to the envisioned consumer of the code: public void
LoadIt(SqlConnection c).  "Loadit" has a bunch of other dependencies
that will be resolved using configuration files and environment
variables: some code has to determine that it can find the name of the
folder where the ISAMs live; to find, load and parse the schema file
for the isams using the ISAM vendor's DDL library; so forth+so on.
But none of that is of any interest to any envisioned calling code.

My only reason for moving the dependency resolvers out of the
Loadit class would be so I could test them OR to make the code easier
to understand/maintain.

Moving to another class to make them testable is Doing It Wrong --
they're really just implementation details of LoadIt.  And in my first
implementation, I am just trying to write enough code to get the light
to turn green.  So I won't write anything with reasonable
maintainability if it's easier to just manhandle a bunch of variables
in a big method or two.  I won't write helper classes.  Instead, I'll
get the light green and then do the Refactor part diligently.  Even
when I clean it up, any classes introduced keep "internal/friend"
accessibility, and only get tested via the call to LoadIt.

Thanks for reading this far; as a reminder, my question is in the
second paragraph.

答:
Well there's scope to it.

I consider testing private methods directly foolish. Internal only in very specific circumstances, instantiating via reflection, using a public method that that calls a factory pattern for instance.

Protected might be wise, given you could be adding to the ancestor class somewhere completely different.

The main reason TDD dies in commercialville is because it gets introduced by some evalgelist type, and they go mad with it. Let them do that and TDD will be "temporarily" postponed while we get some code out of the door, and then postponed again, while we get version 2 done beacseu we didn't have any flipping tests....

Get the basics in there, beef it up as you go along. If you are really fortunate, fill in any when you fix the bugs from UAT, BETA stages.

The developer talent in question is very simple. Only people who know the rules should be able to get away with breaking them.

OwnerDisplayName: MakeMinePanacea

OwnerDisplayName: Tony Hopkinson


答:
The paradigm of object-oriented programming is to have a large collection of simple types that perform a independent unit of work accessed through public interfaces to create a network of communication that can convey tasks being performed in an abstract manner.

When you define a public interface your imposing a permanent constraint on the kind of work that can be performed. When your public interface starts concerning itself with implementing behavior that's not really related to it's focus you provide it in a separate class.

So yes, it's exactly as you described it. You'd have a bullet-proof protocol that wouldn't require any prior tests or consumers to be modified should the implementation of LoadIt() ever change.

What your test could tell you at the point of writing, though, is that by testing such an implementation of LoadIt() you'd be asserting several times over that it can load a ISAM file into the database because you'd have to set it up once that the directory path isn't configured; that it can discover all the ISAM files; that they're being represented in a suitable type. At the time of writing the tests you should observe a pattern emerging that hints that you should actually have a separate class that collects all the ISAM files and test that in isolation.

Well, in TDD, good code reflects good tests and good tests reflect good design principles. Definitely don't burden yourself with trying to get everything right immediately, but if at any point you become queasy and get this creepy feeling it may be evidence of a anti-pattern emerging somewhere nearby. Just write your tests freely and with practice you'll quickly be able to asses whether your taking on a good approach.

Update on comments

Well, what you definitely do apply extensively is building code coverage reports. There is no reason to introduce something that should be private as public for the sake of testing it, but the fact of the matter is that when you simply go for green lights to prove that you understand what is it that your doing, your code will probably be lacking design polish: it'll be tightly coupled into a complex structure where your public interfaces branch of doing varying amounts of work. Your tests will pound against them to assert they're exhibiting correct behavior under all circumstances until you simplify the code structure.

I've practiced testing on my own accord and made my share of mistakes. I'm not the best person to give you a concise educated answer. The problems your finding solutions for require approaches specific to your case. The single most hardest part of testing is when you reach the point that you don't know how and what to test, the circumstances that would force you to sway and abandon TDD and jump straight into the fray and just get it done. You have to think independently and develop a mode of hazard discovery test driving and damage control.

Having said that, I guess there is an aspect to applying TDD that you have to develop an approach for circumstances where your clueless as to how the implementation is supposed to turn out. We don't always operate within the boundaries of a well-defined architecture, working with specialized components that form groups of objects that have established patterns of communication that we fully understand and are comfortable to test against, sometimes you just need to start off with a mess.

Say that the implementation of LoadIt() was potentially volatile. What you do know is that all the tests up to that point are clear and simple. That means your can safely assume your public interfaces are properly designed, a bullet-proof protocol, which means you've isolated the development efforts away from the rest of the application.

I would say that on a per-situational basis anything goes. You then write tests to the best of your ability: write implementations and continue tracing your progress and refining the tests bit by bit. If you reach a point that your describing non-trivial code that seems to be closely related and resembling something that's well asserted, you refactor and extract it into an isolated component, come back to LoadIt(), simplify the tests and continue on, constantly reiterating.

For more involving examples, when your forced to venture deep into the unknown, you can start doing interactive programming or build small prototypes to get your bearings and work your way backwards and write tests as new insight arise, but even in such cases it should be that you have are containing the volatile code and surrounding every entry point: which is to say, never loose safe ground.

So in essence, you can cut to the chase and just go for green lights, but don't forget to apply at least some damage control when you leave code lying around that's not spacecraft-grade. At times you can be satisfied that the work being performed is at the very remote edge of your network with few consumers and defer from refactoring immediately; depending on your refactoring policy, you can wait to refine the design after you let everything settle in a bit or have more time, for the sake of maintainability, but definitely refactor if you ever revisit the code again and need to introduce new changes--it's just like putting flame to fire if you ignore that the existing tests require more attention.

Title: Does not testing internals entail diligent refactoring and/or rely on developer talent?

Body:
I'm not asking here what the arguments are for/against testing
internal methods (though I'll restate some, and don't mind hearing
others). My questions relate to the implications of only testing
public interface.  Especially, whether I understand the extent of the
"refactor" part of Red-Green-Refactor in by-the-book TDD, and if there
are non TDD techniques TDD practitioners use that address the problems
that make me want to test internals.

My question is: If you write the most straightforward code possible to
get the light green, and if you don't test internal methods, does it
follow that from time to time you allow yourself to start off by
writing a class that does far more than it should with a bunch of
member variables you know will not survive refactoring?  And wind up
after refactoring with a bunch of methods that aren't explicitly
tested?

As I get familiar with TDD, it feels like anyone would at least be tempted to
test internal methods.  And many practitioners flatly say you shouldn't.
E.g. (of about 23 million results):

Item 2 here and it's comments and this StackOverflow post

Given an implementation will involve more than one non-trivial
problem, if you only test the public interface, there are two
possibilities: 1) non-trivial logic winds up getting tested only
indirectly, AND tested in the same calls as other non trivial logic.  2) you make methods
public that you don't expect clients other than the SUT and the tests
to call.  I think what I hear from the advocates of by-the-book TDD is
"1 is right.  Yes, a lot of non trivial code is tested only
indirectly, and that isn't a problem.  After all, you don't want your
tests to start failing when you improve the implementation.  Even if
they don't fail, it's not innocuous if tests keep passing when they're
targetting a bunch of no-longer-used code, because the tests show how
to use your class. You Should Only Test the Public Interface."  And
that sounds like a reasonable thing to say, but I haven't seen it said
explicitly.

But even though it sounds reasonable -- if I don't test internals I
feel like I lose part of what helps keep the tests DRIVING the coding
(maybe part of my difficulty applying the precepts is that I don't
distinguish between coding and developing).  If there's some internal
logic that has to turn a String to a valid int32, int64 or decimal
value depending on what's in the string and the type of some other
object, I want to test that little bit of logic, not just find out
that the whole method failed.  I want one test to pinpoint those few
lines of code and exercise what should fail.

The thinking in the doubly downvoted answer here seems so obviously attractive that I have to wonder if the
by-the-book fellows are neglecting to mention some
instrumentation/tracing/logging code they use in addition to TDD, or
if they watch it work in a symbolic debugger.  Or do they just
recognize that as a failure point and write a test with input that
will cause a failure pinpointing those few lines of code?  If they do
that it's testing the implementation though.  It seems so natural to
want to test that code in isolation, and verify it fails where it
should, even though it's an implementation detail.

I suppose that with talent and experience you can classify bigger chunks
of code as "non-trivial" but I haven't seen anyone bluntly saying or condescendingly implying that
that's why they don't have to test implementation details.

Lots of time it makes perfect sense to me to test the public
interface, lots of methods really are like what you see in TDD
examples.  But for the feel of where I wonder if purists are doing
something more than writing tests on a public member: Say you want to
put data from an ISAM file into a database.  There is one public
method to the envisioned consumer of the code: public void
LoadIt(SqlConnection c).  "Loadit" has a bunch of other dependencies
that will be resolved using configuration files and environment
variables: some code has to determine that it can find the name of the
folder where the ISAMs live; to find, load and parse the schema file
for the isams using the ISAM vendor's DDL library; so forth+so on.
But none of that is of any interest to any envisioned calling code.

My only reason for moving the dependency resolvers out of the
Loadit class would be so I could test them OR to make the code easier
to understand/maintain.

Moving to another class to make them testable is Doing It Wrong --
they're really just implementation details of LoadIt.  And in my first
implementation, I am just trying to write enough code to get the light
to turn green.  So I won't write anything with reasonable
maintainability if it's easier to just manhandle a bunch of variables
in a big method or two.  I won't write helper classes.  Instead, I'll
get the light green and then do the Refactor part diligently.  Even
when I clean it up, any classes introduced keep "internal/friend"
accessibility, and only get tested via the call to LoadIt.

Thanks for reading this far; as a reminder, my question is in the
second paragraph.

OwnerDisplayName: Filip Dupanović


答:
So when I was at uni (a while ago now), I was told that UML was the future, UML will replace programming and we'll just generate code from diagrams etc.

They were wrong.  That will happen about the time people abandon speech and go back to cave painting.

Real-world problems, and the programs that solve them, have an essential complexity that cannot be reduced.  To produce a working program, that complexity must be captured and expressed in some executable language.  The question is whether some diagrammatic programming language could be more effective than a textual programming language.  We have been experimenting with diagrammatic programming for about thirty years, and so far the evidence is overwhelmingly in favor of textual programming.  I'm not aware of any important application that has been produced by code generation from diagrams.

Title: Is code commonly generated from UML?

Body:
So when I was at university I was educated on the benefits of UML and its future in code development.

But from my industry experience, I've found that while we do use diagrams—ranging from ER diagrams, class diagrams, state diagrams, to work flow diagrams—all of it is for communication purposes.

That is, I've never generated code automatically from diagrams, and from a communication standpoint, I generally try to keep my diagrams as simple and easy to understand as possible.

But when I look at Visio and Enterprise Architect, it seems they have many different types of graphs, shapes, properties objects, most of which I don't use.

Do people use UML to do more sophisicated things such as code or database generation?


答:
all of it (modeling diagrams) is for communication purposes

Modeling has 4 important usages in the software development process:

Integrated Design tool

Communication tool

An aid to software generation

A way to reduce complexity of real-word problem (I learned this from @kevin cline's response above)

The process of modeling gets some designers to think about details not considered while coding (and vice verse). Modeling at design time allows you to consider a bigger picture than coding a method or a class in a language.

Modeling in my opinion is vital for building databases (ER Diagrams), understanding process flows (Activity Diagrams) and understanding user-system interactions (Use Case diagrams).

Do people use UML to do more sophisicated things such as code or database generation?

Yes indeed. ERDs (not a UML diagram) and Class Diagrams can be used (depending on the capabilities of your tool) to generate:

1 - Data Definition Language (DDL)

2 - Stored Procedures for CRUD and Class Diagrams in your preferred language (less useful since ORM tools do more about this)

Amongst the most valuable features of modeling tools are:

1 - Ability to keep integrity of the model. If you do a change it propagates in the model

2 - Ability to answer where-used questions (where is the 'account' used in my model?)

3 - Ability to allow concurrent users to work on the model

4 - Search within graphical representations

5 - Printing control

6 - Layering (organize your diagram elements in layers) so that you can focus on a layer-at-a-time

7 - Database code generation for several database systems

8 - Model validation (checks consistency, missing keys, cycles, etc.)

So, modeling tools, specially the good ones, do much more than Paint.

Title: Is code commonly generated from UML?


答: Are you after a code review tool. Give you use GIT, have a look at Gerrit. Even if you don't want code review, it may provide what you are seeking. </p>

Title: Ways of marking changes being made to a file

Body: I am looking for a lightweight way to notate changes made to a file. The obvious answer to this is a version control system. But this is more robust than necessary for what I would like to do. All I want is the functionality to compare an edited file to its original in a lightweight manner.</p>


问:
Are there areas where TDD provides a high ROI and other areas where the ROI is so low that it is not worth following?
Test driven development. I get it, like it.

But writing tests does require overhead. So should TDD be used universally throughout the code base, or are there areas where TDD provides a high ROI and other areas where the ROI is so low that it is not worth following.

答:
To me, TDD is not overhead.  It's just the way I write code.  Why is it that you say that writing test is "overhead"?  It's just part of the process.  My point of view is that debugging is overhead, and that is an activity that I essentially stopped doing when I started TDD-ing.  Before TDD, debugging was an integral part of my software writing process.

I think that giving up debugging for test-writing is a very good bargain.


问:
How do quick & dirty programmers know they got it right?
If you ask programmers why they should write clean code, the number one answer you get is maintainability.  While that's on my list, my main reason is more immediate and less altruistic:  I can't tell if my new code is correct if it's too dirty.  I find that I have focused on individual functions and lines of code so much that when I finish my first draft and step back to look at the big picture again it sometimes doesn't fit together very neatly.  Spending an hour or two refactoring for cleanliness frequently uncovers copy/paste errors or boundary conditions that were very difficult to detect in the rough draft.

However, some people feel it's occasionally okay to intentionally check in dirty code in the interest of shipping software, with a plan to "clean it up later."  Is there is some practicable technique that gives them confidence in the correctness of their code when the readability is less than ideal?  Is it a skill worth trying to develop?  Or is a lack of confidence in the code something some people just find easier to accept?

答:
Here's a story about a quick and dirty programmer I know.

I've known a person who regards unit tests a waste of time. After much argument, he finally wrote one. It consisted of one long method sprinkled with && and || and returned a boolean to assertTrue. The statement span 20 lines. Then again, he wrote a class where every method had one line and a main one had over 1000 lines with no whitespaces. It was a wall of text. When I reviewed his code and inserted some new lines, he asked 'why'. I said 'Because of readability'. He sighed and deleted them. He put a comment on top "Don't touch it, it works!"

Last time I talked to him, he coded a website for a company. He was trying to find a bug. He had spent the last 3 days doing that for 8 hours a day. A bit later I talked to him again, and it turned out his team mate changed the value of a literal and didn't update it else where. It wasn't a constant. So he changed the other literals too so that his bug got fixed. He complained about his team mate's spaghetti code. He told me 'Haha, don't we all know what it's like to stay up whole night with the debugger, not getting any sleep over one nasty bug" He think this is something really good programmers do and he actually feels good about it.

Also, he thinks reading programming books and blogs is useless. He says, 'just start programming'. He's done that for 12 years and he thinks he's an excellent programmer. /facepalm

Here's some more.

Another time we were writing a DatabaseManager class for our web app. He put all database calls in it. It was a God class with over 50 methods for every imaginable thing. I suggested we break it up into subclasses because not every controller needs to know about every database method. He disagreed, because it was 'easy' to just have one class for the whole database and it was 'fast' to add a new method whenever we needed one. In the end, DatabaseManager had over 100 public methods from authenticating the user to sorting archaeological site locations.


问:
Developing a Configurable Pricing Program
The organization I work at has some interesting requirements when it comes to pricing for online commerce.  Currently the developers write different 'pricing rules' and those rules can be applied to our items based on attributes of the items.

For Example:

  INPUTS: [cost, sug_retail, discontinued, warehouse_qty, orderable_qty, brand, type, days_available, shipping_rate, weight, map_protected, map_discount]

  MATCH: brand=x, warehouse_qty > 1, discontinued=True, map_protected=False

  SET: retail_price = (sug_retail * 0.95), offer_price1 = (cost * 1.25 + shipping_rate)

I am looking to allow the merchandising team to have more control over the pricing and formulas - they are afterall technical enough to write excel formulas.

I've been looking at writing a desktop application that uses something like numexpr http://code.google.com/p/numexpr/ or http://sympy.org/en/index.html to allow non-programmers to integrate their own logic into our pricing backend.

We have multiple price-tiers we have to set, for multiple markets, so an elegant solution is needed.  It's getting frustrating for the dev team to continually tweak/manage all of the pricing rules (we sell over 200 brands in 3 markets).

My question is; does this seem like a decent approach?  Can you think of a better way to parse string-mathematical-grammer?  Can you think of a different way for users to provide formula's to integrate into a automated pricing system?
Does anyone know of any examples of existing applications that do this?

Excel, and Access are out of the question - the volume of data we manipulate has already proven the need to automate it - now we just need some visibility into that automation.

答:
For E-Commerce organizations agility is at the core of business efficiency.  Being ready for the ever-changing market and keeping pace with business requirements is more challenging and requires that careful selections be made in the development of user-configurable programs.

Configurable programs incur a great risk to the organization if they do not implement, limit, expose business logic properly as to keep configuration inline with business constraints.

There are good examples of configurable commerce solutions, the solutions are generic but offer a good suite of features for consideration.
IBM's WebSphere Commerce Feature Pack 2 features this type of configurable integration.
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.wcs/wcs/7.0.0.2/BusinessUI/PriceRuleOverview/player.html

The rate of expected change at most E-Commerce companies requires areas of the Enterprise Architecture to be extremely stable, and configurable.  Pricing is unfortunately one of those areas, and without at least IT-Configurable rules, keeping pace with day-to-day  changes is impossible.

Having a single algorithm for pricing management becomes more suspect when you think about change-based updates.  When a master algorithm is updated, it means that ALL inputs, outputs, and intermediate variables must be recalculated even if the changes to the algorithm only affect 10% of the data set.  This fact alone suggests it is a flawed approach, and something more horizontally scalable must be considered.

From a business perspective the lost opportunity cost of turning our backs on highly customizable and accessible pricing routines is also unacceptable.