The verbs, nouns, semantics and such used in a given programming language have nothing, I repeat... NOTHING to do with performance!
What does have to do with performance is the talent of the compiler / interpreter author, nothing more, nothing less.
The empirical evidence then tells us that the authors of assemblers are more talented than those of C compilers, who are in turn more talented that the authors of compilers/interpreters of JITs and dynamic languages. Put another way, you're wrong.
Heh - I have not actually been advised of anything, although my understanding is based on the OpenBSD/Apache issue (who'd have guessed?).
I think my phrasing here was bad - I am well aware that two such works could be combined, and the resulting work would be part under one license and part under the other.
The problem is that the _effective_ license of the combined work becomes the Apache license. That is, in order to deal in the work you must follow the rules of both, and the Apache license completely encompasses the new BSD license and adds additional clauses (patent license, contribution clause, etc), so to "follow the rules of both" you must effectively follow the Apache license.
So you release code under the Apache License v2, hoping for it to be widely reused. But a project that is BSD licensed will not use the code, because doing so will change the effective license of the project from BSD to Apache. (the project as a whole is now the combined work, and it must follow the rules of both licenses). That will probably not be acceptable to the project's maintainers. Neither will the code be used by the GPLv2 community as the Apache v2 is incompatible with the GPL.
Assuming my primary concern is to allow anyone to use the code, is anything I've said here incorrect?
Bruce, you've cited patent protection as a good reason to use the Apache License (in your article and in several comments here).
But my understanding is that the Apache License v2 is "less free" than the newBSD/MIT licenses. That is, if I release a work under Apache License v2 it cannot be incorporated into another work or collection that is newBSD/MIT licensed.
It seems to me that the patent protection clause splits the "gift" category into two. If the developer's intention is to allow the work to be as widely used as possible, is the Apache License v2 really the right way to go?
ECC is not a new crypto algorithm. It has been around since 1985, it is will studied, and it is recommended for use in the US (NIST, NSA Suite B), in the EU (NESSIE project falling under the European Commission), and in Japan (CRYPTREC government project).
Bernstein has created a new curve for use with ECC; one that is better suited to the requirements of this particular application than other existing curves. He claims to have followed the appropriate practices in generating this curve -- that obviously needs to be verified by suitably knowledgeable experts.
The "existing algorithm" is RSA, specifically RSASSA-PKCS1-v1_5. There are more secure signature schemes available for RSA, e.g. RSA-PSS. In addition DNSSEC will use 1024-bit RSA keys as a compromise (to reduce transfer size and computational overhead) -- NIST recommendations are that 1024 bits are too short for any purpose.
DNS forgeries are already having a significant impact - keep your eyes on the security reports.
If "large organization" means a publicly listed company or subsidiary then you may want to draw your management's attention to SOX data retention requirements, and the potential criminal penalties for data destruction.
Even if you don't have to be SOX compliant there are various other laws and precedents (see the last link) that should make you want to KEEP e-mail records rather than destroying them, unless you are actively and purposefully involved in criminal activity.
In C or asm you jump to a cleanup block at the end of the function using goto.
Many developers use a deeply nested if/else structure to accomplish the same thing (with much less clarity) because everyone knows that goto is harmful... right?
Everyone also knows that an if() must have an if-not branch (also known as "else") to be "complete".
Because in a fixed pitch font editor a space is always exactly one character wide, but the width of a tab is variable.
I work in an environment where we maintain a LOT of software and firmware bits across a large number of languages and dev environments. We have a couple of projects where the majority of the code base compiles under Visual C, gcc (linux), cc (solaris), and two different embedded compilers.
If you are working on Windows (which most of us do) you will usually edit in the MS Visual C IDE, but sometimes you'll need to use one of the embedded IDEs for debugging. On Solaris we use vi and gdb, and on Linux we use whatever is the nicest thing on the distro we are debugging on (we target 4 different distros).
A space is a space. A tab is different in every IDE/editor. Using spaces instead of tabs is about the only style rule we have in our practice manual.
Good software means lacking in bugs, maintainable, modifiable, scalable, etc...
No, "good software" is a subjective measure.
Programmers almost always define "good software" in terms of source code characteristics (including design, structure, layout, and derived qualities like perceived maintainability and scalability).
Users define "good software" in terms of the user experience with includes ease of use (for the task they intend to accomplish), look & feel, and bugs (including user errors!).
The manager on the customer's side who has budgetary control and final responsibility over the software acquisition will define "good software" to include correctness (meets requirements specification) and promises of maintainability and scalability.
Charles Connell asserts that "Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it." How would a layman know if the design of a bridge was bad; or if the bridge was functionally sound despite an outward appearance of rot or corrosion? Many people are afraid of rope bridges, but this negative user experience doesn't prevent them from being useful for particular applications.
The correct definition of "good software" involves quality attributes that are agreed on by all interested parties. Quality cannot be defined in the absence of the consumer. Given real-world budgetary constraints a slow application with a buggy UI may be acceptable to a customer if data reliability is guaranteed. An imperfect tool is often more valuable than no tool at all.
In November 2007 there was a shootout at my local shopping center during an attempted jewelery heist. The center management decided to post security guards at all entrances, ostensibly to prevent such incidents from happening in the future.
What's wrong with this picture?
The security guards are not law enforcement officers and cannot physically interfere with you or detain you. They get upset when you just walk/push past them, but they can't actually stop you.
The guards are only present 8:30AM to 12PM, offering ample opportunity to enter the center and plant your weapons inside.
The guards search your body if you are male (using a metal detector wand) or your handbag if you are female (visual inspection). Women and children can carry weapons on them without trouble. If you want to bring in a lot of weapons at once put them in a box (say a TV box "for return"), or in a shopping cart.
Some entrances only have one guard, who is entitled by law to lunch and rest breaks...
Some service entrances were - so far as I am aware - unguarded.
If you are carrying a firearm - even with a permit/license - you will not be allowed to enter the center (unless you are a law enforcement officer). This may prevent future shootouts but makes further heists less risky as there will be no armed civilians.
Oh wait: private cash-in-transit security are permitted in to pick up cash... with automatic weapons... even in peak hours... despite recommendations that they should be restricted to service entrances and corridors.
Did it work? Perhaps. There have been no further heists. Much like in the years preceding this incident. The werewolf deterrent in my fridge also appears to be working...
I have worked at several companies where I have had to drag the team into following some sort of agreed practice. I'm not saying a "best practice" because hardly anyone has metrics to prove that their practice gives them a competitive advantage. I'm not even saying a "documented practice" because that would be asking too much. This is more of a "gentleman's agreement" on the minimum level of work that will be accepted.
In my experience any change you propose will face resistance from your co-workers and management if it appears to involve more work. This means that anything you try to introduce must have a clear and immediate advantage that actually reduces workload (and/or reduces cost).
Straight off the bat you can forget about coding style. It's where most practice-mongers start, and it's why most attempts at introducing "best practices" fail. No only do you force your team into a religious conflict, the benefit of a Single Enforced Coding Style is marginal (and there is academic research to back that up). Once you have buy-in for the value of practices, introduce two simple rules to handle coding style: (1) within a file maintain the style; (2) don't restyle an entire file (it wastes time and makes version diffs impossible, especially if everyone starts doing it).
You can also forget about taking the stair machine to Agile. You boss and peers aren't going to buy pair programming or that amount of unit testing (and certainly not writing the tests first).
Step 1 is to introduce source control. Use something Really Bloody Simple. Visual Sourcesafe if you can. Subversion with a GUI client if you can't. Don't restructure projects to make them play nice with source control; don't use branching and all the other advanced crap. Stick to the basics. Check out, change, check in, tag/label occasionally. Focus on the value proposition: everyone has access to the code, the repository is an "extra network copy" in case your development PC crashes, and you can diff between versions which makes finding out what you broke REALLY easy. Tags/labels allow you to easily find the last known-good build.
Step 2 is to introduce MINIMAL documentation standards. Encourage developers to put a one-liner at the top of each function saying what it is _intended to do_. Then state what it is supposed to return. That's it. Anyone maintaining code will see the value of this level of documentation very quickly, and will start bitching at developers who fail to document their functions. Point to you.
Step 3 is to introduce DBC (Design By Contract (TM)), or part thereof. DBC is IMHO the first step to bug reduction and improving the ease of debugging. Every function must be able to return a valid answer or an error, and must start by checking all of its parameters. EVERY function. Even that inner inner loop that has to be fast because otherwise the universe will end. If you were working on something that really had to be that fast, your team would already be using Best Practices. A Lot. Whenever you call a function, check for errors. Never assume that the function call succeeded even if you Know Deep Down that it Cannot Fail... because It Can.
Another way of looking at this is to remember that every CS 101 course says "check input parameters". You should do so in The Real World as well.
Step 4 is to create a culture of unit testing. But do it right. Test as LITTLE as possible, but test the most likely to fail conditions. Most people write unit tests starting from the simplest cases and working up; don't waste time, go for the jugular. The intermediate cases help in debugging, not in regression testing. If the worse possible cases (especially corner cases) chances are good that the rest works too. Good enough that you're wasting time testing them unless you have a big budget and lots of staff.
If developers resist unit testing, hint subtly that it is a convenient way to shift the blame to others. The unit test on YOUR code fails, so this i
There are far more efficient (and cheap) ways to extract thermal noise from a circuit, and SRAM in particular decays slowly (which is why you have to actively erase it if you are developing FIPS-compliant secure hardware). The technique described on the blog sounds suspicious and too likely to be predictable - statistically figure out which bits are likely to change on a power cycle, then use those bits as your RNG. Hmm!
Seriously, if you are after a RNG for a real security application then you're looking at something that conforms to some sort of security specification, like FIPS 140. FIPS doesn't allow RNGs because even statistical testing can't guarantee their randomness, so you always use an RNG as entropy to seed a PRNG and use the output of the PRNG as your random stream.
So what was the "right" thing to do in that situation?
Train the employee.
At some point you may have to find the guts to fire someone (or ask them to resign), or to admit that you haven't got the guts and step aside (as you did - kudos). But there is a lot that can be done before then, and many managers don't take corrective steps (which is the essence of management).
If an employee keeps doing things wrong, train them. Give them simple tasks under the supervision of a mentor (preferably someone who likes to impart knowledge, not a guru who likes to impress others with their knowledge). Rearrange job responsibilities in a team to give the employee something they can do; for example they could execute tests against a test plan (do X and tick the box), check that best practices are followed (especially procedural practices), etc. This is largely clerical work that doesn't require a lot of skill (one the checklists have been set up), but adds a lot of value, and often doesn't appeal to technical employees.
If your managers are not technically competent, then they shouldn't be taking those decisions.
First, take away the technical choices and leave them with business options. Deciding what functionality is provided in a product is a business option; deciding on the design patterns is a technical choice, as is screen layouts (although customer input is a good idea!). So the options you provide only allow business decisions to be made - the relevant technical decisions are implicit.
Gray areas include choice of technology / development platform (the business needs to retain the relevant skills); and use of third-party libraries (compare cost/risk against in-house development and you can often reduce it to a technical choice).
Second, do the work for them, and make it clear that you have the capacity to make the right choice. Start by presenting the options in quantitative summary form: Option X = % functionality provided, estimated cost, estimated time, estimated risk (% of cost/time). Include a terse description of what distinguishes that option from the others.
Demarcate your area of expertise, and make sure you are and expert. Never argue marketing or financial points with your manager - on the contrary, make it clear that those points are outside your area of expertise. But stand your ground on technical issues.
Third, if you are forced into a position where you have to explain or justify a technical choice (note: not explain an option, but justify a decision you have already taken) then use examples and metaphors.
Examples are where you point out how it has been done that way by Microsoft and Google, and millions of people are familiar with it, so it's The Right Thing.
Metaphors are where you find a real-life tale within your manager's experience that focuses on the distinction between technical options, driving a wedge into the gap between them to make it easier for a non-technical person to identify and understand the differences.
It provides a coloured bar (yellow/green) for HTTPS connections in which a user-provided identifier is displayed. So you type in the secure site's URL the first time (https://my.bank.com/), then enter an identifier in the petname bar ("Online banking (Twylite)"). Every time you connect to the site in future the extension will pick up an exact match on the domain name and change the bar to green. Other untrusted SSL sites get yellow. Non-SSL sites are white.
1. Guilt doesn't come into extradition. You are extradited on suspicion and accusation.
2. Australian courts are not competent to rules on matters of US law. i.e. a guilty plea or verdict in Australian has no binding meaning in the US, and vice versa.
3. A guilty plea is not the same as guilt. Guilty pleas are often entered when it will be difficult to establish that the defendant is not guilty as a plea is likely to result in a lesser sentence. In this case the intent of the plea was clearly an attempt to be tried under Australian law rather than being extradited to the US.
Sounds like Tcl's "trace add execution" statement. The interpreter supports an enter and leave callback on every command or procedure (effectively every line of code). The interpreter always checks for the presence of a registered callback (i.e. the check is built in at compile time and is always executed even when the program is not being debugged). Since Tcl is a script language you can add and remove callbacks dynamically.
Maybe taxable: I buy the sword off of eBay, and trade the sword with somebody else for an item that goes for more money on eBay. Is that taxable? Maybe. If you make a business off of selling items on eBay, it just might be.
If your real-world tax system includes Value Added Tax (VAT), then this is definately a VAT transaction.
Every mechanism to realise real value from virtual goods (characters, equipment, whatever) will constitute either Income, Value Add, or Capital Gains. Exchange of virtual goods for other virtual goods or currency within the virtual world should not attract tax, just as stock swaps don't attract tax (under many tax systems; instead you pay when you convert them to cash or a different asset class).
...and realize that there are real-world consequences for things like harrassment.
Yes... I learned that by appealing to an external authority for enforcement you ostracise yourself from your peer group. I learned that without an external authority you are helpless in the face of aggression. I learned that adults are poor judges who make no distinction between aggression, defense and retaliation. I learned that you can't prove who started it -- it doesn't matter who started it -- and that the victim will suffer the same punishment as the aggressor.
Um, my point here is that maturiy is a process, not a date. I'm not arguing about the need to have a date (since we can't assess maturity on an individual basis), but about the idea what we must completely shield people under that age from the stuff they will encounter and have to deal with as adults, thereby preventing the process of maturity, and ensuring that they WILL be children rather than adults at that date.
Emphasis here is on completely shield. Obviously non-adults need greater protection than adults, and can hold less responsibility than adults (and thus have less rights), but there needs to be balance. If you don't have the experiences you need in yout formative years then, well, you don't form right.
Now you see, that's called "assault", and it's a crime no matter what the age or location. Capturing and distributing it means you are making evidence against yourself widely available (read: stupid), so that the cops can enforce the law against "assault". No need for special laws involving bullying.
Adults don't magically gain maturity on reaching 18 or 21. Maturity is gained through a process of learning to have a thick skin... and that starts very young.
Bullying can only occur when there is a disparity between the aggressor's ability to attack, and the victim's ability to defend. Thus "nerds" being the victims of bullying "jocks".
Now along comes the Internet, and Oh Crap! Jonny Football Hero can't physically bully Nedrick the Nerd anymore, or he's going to have himself photoshopped into a very compromising position and plastered on the bathroom walls.
Taunting has long been the only weapon of the victim of physical bullying. The Institution doesn't give a rat's arse unless they manage to catch a bully in the act. The only "problem" here is that now nerds have given taunting a power-up with technology, to the point that it is actually an effective weapon for a counter-attack.
Children are also more likely to engage in sociopathic behaviour towards their peers.
Although that this statement is completely unfounded, it makes a good point for enforcing rules against physical bullying and leaving free speech the hell alone. It's not coincidence that school shootings are carried out by unpopular, downtrodden kids. If a little more attention was paid to making the True American Football Players realise that being a wimp isn't Unamerican and worthy of being pushed around, then (a) the 99.8% of school football players who don't turn it into a career will get better jobs working for the wimps, and (b) the wimps are less likely to prove that they are clever enough to take out the entire class by applying a bit of forethought (bring a gun) and less weightlifting.
Or, more generally: rights come with responsibilities
I can't believe I had to scroll down this far to see this statement. Then again, this is Slashdot:(
The relationship between rights and responsibilities is precisely why children have more limited rights than adults, and why human rights are not absolute (your rights to liberty can be reduced as a result of your behaviour which violates rights of others - e.g. jail time for murder).
It may be reasonable for certain animals that show child-like behaviour and comprehension to enjoy similar rights to children, but even then not quite as extensive as those of children. For example, freedom of movement would be problematic as chimps can be dangerous and can't be held responsible for violent behaviour.
Yes. Never had to use assembler. C compilers do a much better job of optimisation.
What about really low level firmware stuff?
Yes. Had to use an asm {... } block in C once or twice -- that doesn't exactly constitute knowing how to program in assembler.
There are very few good reasons to use asm these days. And I'm saying that as someone who has written a lot of asm code in the past (mostly 8086 and 80386).
CS students certainly shouldn't be learning asm. That's now the realm of EE students and practitioners.
If you really want the Win32 model, it is easy enough to build it on top of PThreads
From me (the grandparent):
Cough. Bullshit. Cough. Read Porting of Win32 API WaitFor to Solaris Platform [sun.com] to get a clue.
It is not easy to build the Win32 model on Pthreads. The WaitForMultipleObjects emulation is a complete hack that pretty much re-implements the Win32 scheduler in userland. Even then it doesn't support a number of synchronization objects that Win32 can (e.g. threads, so that you can wait for thread termination). And it won't work properly unless the underlying *nix scheduler displays round-robin characteristics (anything with historical scheduling will cause a Producer-Consumer arrangement that works perfectly on Win32 to display massive latency on *nix).
The Solaris WaitFor described in that document works only with Event objects. You can't wait on anything other than events like you can in Win32, and you can't link Solaris file IO states (i.e. readable or writable) to those emulated events.
So you can't construct an instruction like "Wait for socket X to be readable OR event QUIT to be signalled", which is quite possible in Windows. In fact you can't do that at all on any *nix system that I am aware of (not even with kqueue or dev/poll to my knowledge). Instead you loop checking QUIT then doing a select()/poll() X with a timeout.
Slashdot Mirror
The verbs, nouns, semantics and such used in a given programming language have nothing, I repeat... NOTHING to do with performance!
What does have to do with performance is the talent of the compiler / interpreter author, nothing more, nothing less.
The empirical evidence then tells us that the authors of assemblers are more talented than those of C compilers, who are in turn more talented that the authors of compilers/interpreters of JITs and dynamic languages. Put another way, you're wrong.
Heh - I have not actually been advised of anything, although my understanding is based on the OpenBSD/Apache issue (who'd have guessed?).
I think my phrasing here was bad - I am well aware that two such works could be combined, and the resulting work would be part under one license and part under the other.
The problem is that the _effective_ license of the combined work becomes the Apache license. That is, in order to deal in the work you must follow the rules of both, and the Apache license completely encompasses the new BSD license and adds additional clauses (patent license, contribution clause, etc), so to "follow the rules of both" you must effectively follow the Apache license.
So you release code under the Apache License v2, hoping for it to be widely reused. But a project that is BSD licensed will not use the code, because doing so will change the effective license of the project from BSD to Apache. (the project as a whole is now the combined work, and it must follow the rules of both licenses). That will probably not be acceptable to the project's maintainers. Neither will the code be used by the GPLv2 community as the Apache v2 is incompatible with the GPL.
Assuming my primary concern is to allow anyone to use the code, is anything I've said here incorrect?
Bruce, you've cited patent protection as a good reason to use the Apache License (in your article and in several comments here).
But my understanding is that the Apache License v2 is "less free" than the newBSD/MIT licenses. That is, if I release a work under Apache License v2 it cannot be incorporated into another work or collection that is newBSD/MIT licensed.
It seems to me that the patent protection clause splits the "gift" category into two. If the developer's intention is to allow the work to be as widely used as possible, is the Apache License v2 really the right way to go?
ECC is not a new crypto algorithm. It has been around since 1985, it is will studied, and it is recommended for use in the US (NIST, NSA Suite B), in the EU (NESSIE project falling under the European Commission), and in Japan (CRYPTREC government project).
Bernstein has created a new curve for use with ECC; one that is better suited to the requirements of this particular application than other existing curves. He claims to have followed the appropriate practices in generating this curve -- that obviously needs to be verified by suitably knowledgeable experts.
The "existing algorithm" is RSA, specifically RSASSA-PKCS1-v1_5. There are more secure signature schemes available for RSA, e.g. RSA-PSS. In addition DNSSEC will use 1024-bit RSA keys as a compromise (to reduce transfer size and computational overhead) -- NIST recommendations are that 1024 bits are too short for any purpose.
DNS forgeries are already having a significant impact - keep your eyes on the security reports.
The only thing anyone needs to know about OpenID is that it relies on the security of DNS.
If "large organization" means a publicly listed company or subsidiary then you may want to draw your management's attention to SOX data retention requirements, and the potential criminal penalties for data destruction.
Some links:
- http://digg.com/security/E_Mail_Retention_Sarbanes_Oxley_White_Paper
- http://www.creditworthy.com/3jm/articles/cw90507.html
- http://www.soxfirst.com/50226711/email_retention_the_legal_chernobyl.php
Even if you don't have to be SOX compliant there are various other laws and precedents (see the last link) that should make you want to KEEP e-mail records rather than destroying them, unless you are actively and purposefully involved in criminal activity.
In C or asm you jump to a cleanup block at the end of the function using goto.
Many developers use a deeply nested if/else structure to accomplish the same thing (with much less clarity) because everyone knows that goto is harmful ... right?
Everyone also knows that an if() must have an if-not branch (also known as "else") to be "complete".
Because in a fixed pitch font editor a space is always exactly one character wide, but the width of a tab is variable.
I work in an environment where we maintain a LOT of software and firmware bits across a large number of languages and dev environments. We have a couple of projects where the majority of the code base compiles under Visual C, gcc (linux), cc (solaris), and two different embedded compilers.
If you are working on Windows (which most of us do) you will usually edit in the MS Visual C IDE, but sometimes you'll need to use one of the embedded IDEs for debugging. On Solaris we use vi and gdb, and on Linux we use whatever is the nicest thing on the distro we are debugging on (we target 4 different distros).
A space is a space. A tab is different in every IDE/editor. Using spaces instead of tabs is about the only style rule we have in our practice manual.
No, "good software" is a subjective measure.
Charles Connell asserts that "Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it." How would a layman know if the design of a bridge was bad; or if the bridge was functionally sound despite an outward appearance of rot or corrosion? Many people are afraid of rope bridges, but this negative user experience doesn't prevent them from being useful for particular applications.
The correct definition of "good software" involves quality attributes that are agreed on by all interested parties. Quality cannot be defined in the absence of the consumer. Given real-world budgetary constraints a slow application with a buggy UI may be acceptable to a customer if data reliability is guaranteed. An imperfect tool is often more valuable than no tool at all.
The most important reference you need is ISO 9126 which provides a quality model for software. The Wikipedia page on Software quality is also worth reading, and you may find ISO/IEC 14598 (Software Product Evaluation) worthwhile as well.
In November 2007 there was a shootout at my local shopping center during an attempted jewelery heist. The center management decided to post security guards at all entrances, ostensibly to prevent such incidents from happening in the future.
What's wrong with this picture?
Did it work? Perhaps. There have been no further heists. Much like in the years preceding this incident. The werewolf deterrent in my fridge also appears to be working...
I have worked at several companies where I have had to drag the team into following some sort of agreed practice. I'm not saying a "best practice" because hardly anyone has metrics to prove that their practice gives them a competitive advantage. I'm not even saying a "documented practice" because that would be asking too much. This is more of a "gentleman's agreement" on the minimum level of work that will be accepted.
... because It Can.
In my experience any change you propose will face resistance from your co-workers and management if it appears to involve more work. This means that anything you try to introduce must have a clear and immediate advantage that actually reduces workload (and/or reduces cost).
Straight off the bat you can forget about coding style. It's where most practice-mongers start, and it's why most attempts at introducing "best practices" fail. No only do you force your team into a religious conflict, the benefit of a Single Enforced Coding Style is marginal (and there is academic research to back that up). Once you have buy-in for the value of practices, introduce two simple rules to handle coding style: (1) within a file maintain the style; (2) don't restyle an entire file (it wastes time and makes version diffs impossible, especially if everyone starts doing it).
You can also forget about taking the stair machine to Agile. You boss and peers aren't going to buy pair programming or that amount of unit testing (and certainly not writing the tests first).
Step 1 is to introduce source control. Use something Really Bloody Simple. Visual Sourcesafe if you can. Subversion with a GUI client if you can't. Don't restructure projects to make them play nice with source control; don't use branching and all the other advanced crap. Stick to the basics. Check out, change, check in, tag/label occasionally. Focus on the value proposition: everyone has access to the code, the repository is an "extra network copy" in case your development PC crashes, and you can diff between versions which makes finding out what you broke REALLY easy. Tags/labels allow you to easily find the last known-good build.
Step 2 is to introduce MINIMAL documentation standards. Encourage developers to put a one-liner at the top of each function saying what it is _intended to do_. Then state what it is supposed to return. That's it. Anyone maintaining code will see the value of this level of documentation very quickly, and will start bitching at developers who fail to document their functions. Point to you.
Step 3 is to introduce DBC (Design By Contract (TM)), or part thereof. DBC is IMHO the first step to bug reduction and improving the ease of debugging. Every function must be able to return a valid answer or an error, and must start by checking all of its parameters. EVERY function. Even that inner inner loop that has to be fast because otherwise the universe will end. If you were working on something that really had to be that fast, your team would already be using Best Practices. A Lot. Whenever you call a function, check for errors. Never assume that the function call succeeded even if you Know Deep Down that it Cannot Fail
Another way of looking at this is to remember that every CS 101 course says "check input parameters". You should do so in The Real World as well.
Step 4 is to create a culture of unit testing. But do it right. Test as LITTLE as possible, but test the most likely to fail conditions. Most people write unit tests starting from the simplest cases and working up; don't waste time, go for the jugular. The intermediate cases help in debugging, not in regression testing. If the worse possible cases (especially corner cases) chances are good that the rest works too. Good enough that you're wasting time testing them unless you have a big budget and lots of staff.
If developers resist unit testing, hint subtly that it is a convenient way to shift the blame to others. The unit test on YOUR code fails, so this i
Someone who knows what they are talking about :)
There are far more efficient (and cheap) ways to extract thermal noise from a circuit, and SRAM in particular decays slowly (which is why you have to actively erase it if you are developing FIPS-compliant secure hardware). The technique described on the blog sounds suspicious and too likely to be predictable - statistically figure out which bits are likely to change on a power cycle, then use those bits as your RNG. Hmm!
Seriously, if you are after a RNG for a real security application then you're looking at something that conforms to some sort of security specification, like FIPS 140. FIPS doesn't allow RNGs because even statistical testing can't guarantee their randomness, so you always use an RNG as entropy to seed a PRNG and use the output of the PRNG as your random stream.
Train the employee.
At some point you may have to find the guts to fire someone (or ask them to resign), or to admit that you haven't got the guts and step aside (as you did - kudos). But there is a lot that can be done before then, and many managers don't take corrective steps (which is the essence of management).
If an employee keeps doing things wrong, train them. Give them simple tasks under the supervision of a mentor (preferably someone who likes to impart knowledge, not a guru who likes to impress others with their knowledge). Rearrange job responsibilities in a team to give the employee something they can do; for example they could execute tests against a test plan (do X and tick the box), check that best practices are followed (especially procedural practices), etc. This is largely clerical work that doesn't require a lot of skill (one the checklists have been set up), but adds a lot of value, and often doesn't appeal to technical employees.
If your managers are not technically competent, then they shouldn't be taking those decisions.
First, take away the technical choices and leave them with business options. Deciding what functionality is provided in a product is a business option; deciding on the design patterns is a technical choice, as is screen layouts (although customer input is a good idea!). So the options you provide only allow business decisions to be made - the relevant technical decisions are implicit.
Gray areas include choice of technology / development platform (the business needs to retain the relevant skills); and use of third-party libraries (compare cost/risk against in-house development and you can often reduce it to a technical choice).
Second, do the work for them, and make it clear that you have the capacity to make the right choice. Start by presenting the options in quantitative summary form: Option X = % functionality provided, estimated cost, estimated time, estimated risk (% of cost/time). Include a terse description of what distinguishes that option from the others.
Demarcate your area of expertise, and make sure you are and expert. Never argue marketing or financial points with your manager - on the contrary, make it clear that those points are outside your area of expertise. But stand your ground on technical issues.
Third, if you are forced into a position where you have to explain or justify a technical choice (note: not explain an option, but justify a decision you have already taken) then use examples and metaphors.
Examples are where you point out how it has been done that way by Microsoft and Google, and millions of people are familiar with it, so it's The Right Thing.
Metaphors are where you find a real-life tale within your manager's experience that focuses on the distinction between technical options, driving a wedge into the gap between them to make it easier for a non-technical person to identify and understand the differences.
It provides a coloured bar (yellow/green) for HTTPS connections in which a user-provided identifier is displayed. So you type in the secure site's URL the first time (https://my.bank.com/), then enter an identifier in the petname bar ("Online banking (Twylite)"). Every time you connect to the site in future the extension will pick up an exact match on the domain name and change the bar to green. Other untrusted SSL sites get yellow. Non-SSL sites are white.
1. Guilt doesn't come into extradition. You are extradited on suspicion and accusation. 2. Australian courts are not competent to rules on matters of US law. i.e. a guilty plea or verdict in Australian has no binding meaning in the US, and vice versa. 3. A guilty plea is not the same as guilt. Guilty pleas are often entered when it will be difficult to establish that the defendant is not guilty as a plea is likely to result in a lesser sentence. In this case the intent of the plea was clearly an attempt to be tried under Australian law rather than being extradited to the US.
Sounds like Tcl's "trace add execution" statement. The interpreter supports an enter and leave callback on every command or procedure (effectively every line of code). The interpreter always checks for the presence of a registered callback (i.e. the check is built in at compile time and is always executed even when the program is not being debugged). Since Tcl is a script language you can add and remove callbacks dynamically.
If your real-world tax system includes Value Added Tax (VAT), then this is definately a VAT transaction.
Every mechanism to realise real value from virtual goods (characters, equipment, whatever) will constitute either Income, Value Add, or Capital Gains. Exchange of virtual goods for other virtual goods or currency within the virtual world should not attract tax, just as stock swaps don't attract tax (under many tax systems; instead you pay when you convert them to cash or a different asset class).
Yes ... I learned that by appealing to an external authority for enforcement you ostracise yourself from your peer group. I learned that without an external authority you are helpless in the face of aggression. I learned that adults are poor judges who make no distinction between aggression, defense and retaliation. I learned that you can't prove who started it -- it doesn't matter who started it -- and that the victim will suffer the same punishment as the aggressor.
Um, my point here is that maturiy is a process, not a date. I'm not arguing about the need to have a date (since we can't assess maturity on an individual basis), but about the idea what we must completely shield people under that age from the stuff they will encounter and have to deal with as adults, thereby preventing the process of maturity, and ensuring that they WILL be children rather than adults at that date.
Emphasis here is on completely shield. Obviously non-adults need greater protection than adults, and can hold less responsibility than adults (and thus have less rights), but there needs to be balance. If you don't have the experiences you need in yout formative years then, well, you don't form right.
Now you see, that's called "assault", and it's a crime no matter what the age or location. Capturing and distributing it means you are making evidence against yourself widely available (read: stupid), so that the cops can enforce the law against "assault". No need for special laws involving bullying.
Adults don't magically gain maturity on reaching 18 or 21. Maturity is gained through a process of learning to have a thick skin ... and that starts very young.
Bullying can only occur when there is a disparity between the aggressor's ability to attack, and the victim's ability to defend. Thus "nerds" being the victims of bullying "jocks".
Now along comes the Internet, and Oh Crap! Jonny Football Hero can't physically bully Nedrick the Nerd anymore, or he's going to have himself photoshopped into a very compromising position and plastered on the bathroom walls.
Taunting has long been the only weapon of the victim of physical bullying. The Institution doesn't give a rat's arse unless they manage to catch a bully in the act. The only "problem" here is that now nerds have given taunting a power-up with technology, to the point that it is actually an effective weapon for a counter-attack.
Although that this statement is completely unfounded, it makes a good point for enforcing rules against physical bullying and leaving free speech the hell alone. It's not coincidence that school shootings are carried out by unpopular, downtrodden kids. If a little more attention was paid to making the True American Football Players realise that being a wimp isn't Unamerican and worthy of being pushed around, then (a) the 99.8% of school football players who don't turn it into a career will get better jobs working for the wimps, and (b) the wimps are less likely to prove that they are clever enough to take out the entire class by applying a bit of forethought (bring a gun) and less weightlifting.
I can't believe I had to scroll down this far to see this statement. Then again, this is Slashdot :(
The relationship between rights and responsibilities is precisely why children have more limited rights than adults, and why human rights are not absolute (your rights to liberty can be reduced as a result of your behaviour which violates rights of others - e.g. jail time for murder).
It may be reasonable for certain animals that show child-like behaviour and comprehension to enjoy similar rights to children, but even then not quite as extensive as those of children. For example, freedom of movement would be problematic as chimps can be dangerous and can't be held responsible for violent behaviour.
Yes. Never had to use assembler.
Yes. Never had to use assembler. C compilers do a much better job of optimisation.
Yes. Had to use an asm { ... } block in C once or twice -- that doesn't exactly constitute knowing how to program in assembler.
There are very few good reasons to use asm these days. And I'm saying that as someone who has written a lot of asm code in the past (mostly 8086 and 80386).
CS students certainly shouldn't be learning asm. That's now the realm of EE students and practitioners.
From the great grandparent:
From me (the grandparent):
It is not easy to build the Win32 model on Pthreads. The WaitForMultipleObjects emulation is a complete hack that pretty much re-implements the Win32 scheduler in userland. Even then it doesn't support a number of synchronization objects that Win32 can (e.g. threads, so that you can wait for thread termination). And it won't work properly unless the underlying *nix scheduler displays round-robin characteristics (anything with historical scheduling will cause a Producer-Consumer arrangement that works perfectly on Win32 to display massive latency on *nix).
The Solaris WaitFor described in that document works only with Event objects. You can't wait on anything other than events like you can in Win32, and you can't link Solaris file IO states (i.e. readable or writable) to those emulated events.
So you can't construct an instruction like "Wait for socket X to be readable OR event QUIT to be signalled", which is quite possible in Windows. In fact you can't do that at all on any *nix system that I am aware of (not even with kqueue or dev/poll to my knowledge). Instead you loop checking QUIT then doing a select()/poll() X with a timeout.