While I agree that online distribution is a potential boon for the independent developer house, it doesn't have to come at the price of "if we go under, you can't play". Having been bitten by *that* shell game already I refuse to buy any software that requires authentication with the mothership if there is a viable alternative available. There is nothing like upgrading your computer to find that your reg key is missing or invalidated by the upgrade... and that the company either doesn't exist or refuses to issue a new key without a browbeating. I have enough to do each day without battling authentication schemes. (And yes, I have a few disks that fail due to DVD incompatability... that's why I keep a CD drive installed.)
If that was his rewrite rule, I wonder who might be interested in his deliberate exposure of children to that material. This thread is a public admission that he deliberately placed indecent material on a children's site.
I'm not a big fan of censorship or our indecency laws, but placing that image on a children's site seem a bit of an overreaction. On that might come back and bite.
How is this duplication of effort different from any other competing products? Proprietary competitors are exerting "too much effort" producing *encumbered* clones of encumbered products. It would seem that Open Source makes a bit more sense, as once effort is placed in an unencumbered product the product exists and can be built upon, extended or borrowed from. Is the production of a bunch of products that will compete, fail and then take any innovation with them to their grave *better* than the open collaboration that Open Source allows?
Under the argument you propose, Linux was a pointless exercise because it produced a "free" work-alike to an "existing, known-good, encumbered product". Meanwhile, do you think that if the "effort could be used elsewhere" it would have been used to produce something useful, like say another failed Word knock-off? I don't quite see how proprietary dead ends are better than open source clones, which at least have the virtue of being immortal. (I am doubious of the idea that "more effort" equals "more innovation, as you can see).
No, I don't buy the "open source for everything" mantra that is spouted here. Each development method has its advantages. I doubt that Open Source will be invading the vertical markets any time soon as the user and developer base is too small for the advantages of Open Source to be felt. But when you are talking about things that have become "commodity" such as OS, database, office suites, etc then Open Source makes sense... and that's why they aren't very innovative. Open Source is the ultimate expression of commodity good.
The extreme alternative is for all products to be commercial forever, meaning that large companies continue to cash in on less and less innovative products. Office 2003 had exactly one product than made the upgrade worthwhile to me: Outlook. (I.E. a version without the 2GB file size limit). Products like Open Office keep Microsoft honest by forcing them to try to innovate, but to be honest, how much farther can the basic office suite be pushed? If it turns out the answer is "not much farther in core functionality" then by all means allow the ultimate expression of commodity good be created in that market and start to succeed. If the answer is "all over the place" then I guess we will see just how far office suites can be pushed. Everyone is a winner, either outcome. Discounting the "innovation pressure" than Open Source is putting on the commercial vendors I think understates the value of the ultimate commodity good. No, the products are not usually massively innovative, but they force the commercial vedors to be so or perish.
So where *does* one maintain session when cookies and Javascript are blocked? I guess one could force every page navigation to be a form post, but the single target per form would lead to some pretty stupid looking design.
"That's a good thing." Nah, if google has figured out how not to infinite recurse, surely Microsoft can figure it out as well instead of demanding the Internet change in structure to suit its whims.
Note that I agree that where possible session state shouldn't be in the URL, but for maximum compatibility and flexibility while adhering to standards we do maintain session state (simply a ID and security hash to DB state) on the URL. I guess I could turn customers away, but that seems pointless when I don't have to. (And no, Microsoft's algorithmic failure is not equal to "I have to"... robots.txt works just fine until they figure it out.)
Re:More information on boardgamegeek
on
DOOM: The Boardgame
·
· Score: 2, Insightful
Board Game Geek is a site with a focus on "German Style" or "Designer" games. The "perfect" design (to this subgroup of gamers) is one that minimizes luck without removing it: a middle ground between the abstract and luck-fest.
They like fun "bits" (thus Zombies!!! position is high because, hey, glow in the dark zombies) and they dislike "classics" because as a group they are looking for something exciting and new.
Ask the "average American" about boardgames and they will probably list "Monopoly, Risk and party games".
Ask the "average BGG member" about boardgames and they will probably list "Settlers, Puerto Rico and [insert oddball game you have little chance of ever playing here]".
Ask the "average consim (wargame) player" about boardgames and you will get a list of dusty titles with lots of cardboard counters.
The "vote-rigging" isn't really that: it is a reflection of the type of games that the community formed around. To say it is vote rigging is like saying that the ratings of films in a independent film festival must be rigged because [mega hollywould blockbuster X] didn't win.
I would agree that being an "after though" isn't wise... but I have watched many people do really stupid things like "I want this to run as fast as possible so I will cache all my data close to me in objects" only to watch the server thrash pages so hard that it was useless. I have watched the other extreme as well happen: "Let's just hit the DB when I need data" and watched poorly thought our queries bring the system to its knees.
For every algorithm there are trade offs. The most common are memory vs time and some people even think about those. Forgetting that they have to push the data down a narrow network channel which they just been saturated or being unaware of the impact on the disk array of the "clever" access patterns their algorithm creates are common things people forget. Assuming they though through the first part.
Personally, I would prefer to think about these implication and then choose a middle of the road, easy to understand implementation. If testing (please note: not slapping your assumptions into production based on your guesswork, but testing in controlled load test environments) shows that we have made performance errors, only then do we swap in harder to understand algorithms, caching mechanisms and other complexity inducing methods. I would say that 10% of our code has been refactored based on such considerations.
Since our programs are web based and we can swap our underlying mechanisms in a day if necessary, perhaps that gives us more flexibility. Perhaps also because we build business systems where "finding that out at the start of programming" is an absurd thing to say, as regulations changes and business stake holder changes mean that anything we do today is likely to be ripped out in a month or a year. Premature optimization seems foolish in the fact of the reality on the ground: "premature expecting to know what this module will *actually* do" in the real world. I would say that 50% of our code has been refactored (over the course of the five years in business) based on business considerations.
Some days I wish I was writing code for some well defined arena that didn't have stakeholders defining the requirements, but some constraints that remained stable through the hirings and firings and mood swings of the clients. That isn't my world.
So, which "performance" are we optimizing for? Memory footprint? Disk access? CPU utilization? Network utilization?
It turns out you rarely know which will bite your face off until you get a representative data set running. If you made the wrong choice, you probably made things *worse* than if you had opted for working code that could be re-factored from "easy to read" to "mostly easy to read and performs where it counts".
When you are working on server based solutions that will be hit hard, all of those could be your bottleneck: or none.
Actually, the company did proceed with a suit and I had to file for discovery to get a third party tech to discover who owned the files on the drive that caused the problem. The suit was withdrawn upon discovery. Companies react adversly to $13,000 + phone bills with no explanation, which I can understand, to an extent. The weasle who tried to blame me was the companies nominal "administrator", and thus had some credibility with the company. He was fortunately cluesless enough to not cover the tracks that were present in the NTFS permission data on the backups from the time the dialer was active.
Having for a long time intended to link my Linux box to my home LAN's AD, this was just the ticket to try it. Overall things went well, although the instructions completely skip over the actual configuration of the krb5.conf file.
In particular, this is a huge oversite because things don't work as expected. After some googling I discovered that you must specify the domain as MYDOMAIN.LOCAL, all caps. This must be done in several places, otherwise it throws cryptic errors.
With that one proviso in place, I would say the rest of the instructions were sufficient for me to figure it out in 30 minutes. Both directions authenticate properly.
I have considered doing this (and sometimes feel like I am when it comes to family and friends). However, I was advised that the insurance risks to my company were too great, even if I did the work as an individual. Yes, gotta love the good old US legal system, where simply advising someone on how to use their computers makes you exposed to lawsuits for all the unrelated stuff that happens to them afterwords. Since this situation has happened to me in the business world (employee downloads porn dialer on a machine I didn't even touch and then accuses me when it is discovered) already, it's a risk I would prefer not to take. In that case, NTFS was able to help me show the owner that the account used to download the dialer was not the administrative account, but this bozo's account, but I may not always be so lucky.
Re:Not Learnn the API - Learn the Language
on
Defining Google
·
· Score: 1
While I believe that knowing several languages will allow acquisition of additional languages of the same style, procedural programming does little to prepare people for the mental shift to functional/logic/declarative languages. The converse is probably true (I just don't know of anyone who didn't know procedural to start with).
It is for this reason I prefer to hire people with experience with at least one of the languages of these types: it broadens the mind and some of the concepts are very applicable in modern programs, just not well supported out of the box. For example, we have a declarative computation engine in our product. Spell out the formulas you want and we figure out what order to apply them to input data (using similar logic as a spreadsheet uses to determine execution order). This means that even novice users can specify fairly complex computations, as they don't have to worry about side effects, execution order, etc. Just inputs, functions and outputs. Most of the programmers (read: unaware of an alternative to procedural programming) wanted to give our users a scripting language, but it turned out over the years that the declarative method was far more elegant and usable. Since the preprocessor outputs standard procedural code that is used to actually execute the results, we don't even pay a penalty in performance for the declarative style.
The irony here is that most of the people I interviewed who knew how to use both types of languages well were self taught. Schools teach the functional stuff, but do it in a "oh, and the mad theoretical people use this nonsense" manner where the students seem repelled by the idea of actually having to *code* declaratively. Meanwhile, our untrained (in the computer sciences) users love the declarative coding.
I will second this: if you are looking for a bugtracker that works well and is a breeze to install, Mantis is it. I personally use it on LAMP platforms, but I have installed it on Windows on an experimental basis and it worked fine.
I'm a bit confused the the focus of this review. From what I gather, this is an art book. Yet very little of the review discusses the art within. Typos, grammatical errors and orphan control are not what I usually rate my art books on (although layout is important and shouldn't be this shabby). I found the review 100% helpful in regards to the quality of layout and only 20% help in regards to contents, except when it was misspelled.
It is almost like this review needed to be edited by a third party editor...
I'll take it that your work situation isn't very good. If you are being assigned to work at 100% workload you have a poor project manager. Actual working time varies from company to company: we have very few meetings, but we have overhead like anyone else and therefore don't expect 40 hours of assigned work to be completed in 40 working hours.
Unless someone is totally unaware of reality, they should be using the "Working Time" defaults in the scheduling software to exclude meetings and other known overhead. Then for each employee the "Resource Availability" should be set to whatever percentage is reasonable for your environment (which sounds pretty low in your environment: a sign of structural disfunction, not scheduling per-se). Once you do that, if the scheduled hours from the team is reasonable, the schedule will be reasonable. Reasonable doesn't mean perfect, but the goal is for your team to be able to have an average completion time that is within the ballpark of the estimates. Likewise, the amount of working time vs overhead is checked to ensure that extra overhead isn't creeping into the system. That's about all you can do (other than feedback loops on the estimates) to ensure a reasonable schedule.
Regarding "was-supposed-to-be-working" code, we charge those incidents back to the original developer of that change (good CVS commit logs and the schedule make it pretty clear who owned a change). Our estimates include development *and* testing time, which throws a lot of programmers at first because they think they can just toss something together and throw it over the wall. It doesn't take long for the time estimates to start assimilating that requirement though: the programmer will consistently underperform estimates that were made, and after a couple of weeks we will come to a new agreement on estimates. The person who has to make the emergency fix obviously isn't penalized for such an emergency, but more than one in a blue moon of that nature is another sign of a disfunctional organizational system... the owner of repeated emergency repair inducing code won't be with us long unless *that* changes. (Test driven development really helps stop much of that in its tracks).
As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
Yes, I'm aware of that clause... however it used to mean "we can withdraw support from a product at any time and you can't do anything about it". For example, when a company end of lives a product, that clause prevents them from being sued for lack of support, updates, etc. However, I can pull out my old CDs and install any patched I downloaded and have the last version released of almost any package.
Except those with activation. Because... there is nobody to activate it. Now if you are a corporation and buy activation based software, you can hammer out a end of life agreement (that is the foundation of contract law: two parties reaching an agreement). As an individual with no negotiation available on the supposed "contract", the EULA enforces an unconscionable provision.
It will be interesting once a case actually reaches the courts where many consumers are jacked by the untimely death of a company. Something of the magnatude of Intuit going under suddenly leaving all those with Quicken locked out of their financial data. Somehow I don't see the courts buying "we can just up and lock people out" even if the EULA says they can.
I would agree with many of your statements. I have not bought Half Life 2 and will not buy it because of a prior experience with activation based gaming. I dropped a small amount to Real when they came out with Real Arcade. I downloaded a small number of games and played them off and on. Finally, the computer failed and I replaced it. Tossed the old drive in the new machine and found the games didn't work. Called Real and they told me to get bent (short form). Turned out that the games are hardware locked and replacing your hardware invalidated all game purchases. (This was near the product launch, have no idea if it is still so daconian.
So yes: you "bought" a license. Live with the terms. And vote with your wallet, hopefully *before* you get burned.
In my opinion, however, the posters statement you quote is a true statement. You didn't buy anything, you *rented* it, and there is a big difference between buying and renting. People should be aware of that difference. A sticker on the box of HL2 that says "you can play this game until: (we go out of business|decide you can't|want to force an upgraded version on you)" would make that a bit more clear.
Then why do you stay? If this site is "BSD Dying" then get off the URL and save bandwidth for those who still find it amusing. But complaining about "paid subscriptions" when you yourself don't have one (and thus get the content, however flawed you feel it is, for free) is sanctimonious nonesense.
Bravo! Excellent comment: I have always wondered about those who think that the story of Christ has to be "right" when those who believe in him are a minority on the planet. Every other religion makes the same claim to being "right". If this is a popularity contest, Hinduism and Islam look pretty strong. If this isn't a popularity contest, then on what basis should I choose? That the "story sounds good". All religions make an effort to sound good. "That I grew up seeped in these traditions" is what most Christians base their "faith" on, which is as illogical as they come, as that is the same reason that other large religious populations exist and remain stable.
I have always seen religions as the ultimate expression of memes: those that exist today have strong survival traits. The are resistant to outside attack (either by logic or other religious thought patterns), highly transmittable to those without a strong of a meme in place (either by promise of benefits of threats of penalties) and mutable to current conditions (such as the adoption of local custom as part of the base religion to attract converts).
"I'm not afraid of homosexuals any more than I'm afraid of deaf people who want deafness recognized as a normal variation."
What the heck does that mean: that you are unafraid of homosexuals (in which case your concerns about sex lives should end about there) or you are afraid of deaf people who would like to live a somewhat normal life? Because, that sentence combined with the prior sure makes it seem like the latter, which scares the heck out of me. You believe that homosexuality being a normal variation is wrong. Then you draw a parallel between deafness and homosexuality and conclude you have the same feelings about both. Wow. Just wow. Don't even both to respond, I just added you to my "hateful irrationals" list.
That article does point out a major problem with the majority of adventure games. I don't think we will see many more mainstream adventure games of the traditional mold because of that bizarre "logic" that evolved around the adventure game community.
The best part of traditional adventure games were story and the triumph of solving a puzzle. The former (story) could be the part of so many more games than it currently is. One of the reasons I loved Half-Life was that there was a fun storytelling mechanism that never removed the player from the game. The latter (problem solving) is found in only a rudimentary form in most modern games (find key, locks magically open). Illogic puzzles are out, story is in: I don't morn that state, except the lack of more Monkey Island goodness.
Ignoring the creationist throwaway comment, you have a point. However, the reason that iterative design has had a rise recently is the recognition that traditional design has failed to provide business value in many cases. I work in an iterative design methodology, but it is tempered with as much forward though as I can give a product. The realization that I think has to be made is that no person or team can forsee all requirements and therefor even the obstinately linear design will be iterative, and often the processes are not in place to handle the required iterations when the mindset is *to* linear.
I have created many large systems for companies. I have also created many small systems. The reality on the ground is most large systems *grow* out of small systems. Yes, I try to think ahead and plan for growth, but you never know which systems *will* grow and which will be one off throwaways. Often the systems that business people are gunning for "big picture" implementations are the ones that get tossed the fastest. Meanwhile, some of the systems that would have seemed to be total tangents have grown into core systems.
Business reality is composed of one core truth: change or die. Grand designs of linear nature are not good for handling that environment. Now there may be some areas where grand design is possible (I would think that more core science/math based software, or well understood problems like operating systems and programming languages would be good counter examples) but in the realm I work in, where managers change direction on a daily basis, integration requirements change weekly and customer directions change monthly, I would challenge any "grand design" to stand and deliver what iterative design can.
Slashdot Mirror
While I agree that online distribution is a potential boon for the independent developer house, it doesn't have to come at the price of "if we go under, you can't play". Having been bitten by *that* shell game already I refuse to buy any software that requires authentication with the mothership if there is a viable alternative available. There is nothing like upgrading your computer to find that your reg key is missing or invalidated by the upgrade... and that the company either doesn't exist or refuses to issue a new key without a browbeating. I have enough to do each day without battling authentication schemes. (And yes, I have a few disks that fail due to DVD incompatability... that's why I keep a CD drive installed.)
Off topic: WTF is up with the manual line breaks?
If that was his rewrite rule, I wonder who might be interested in his deliberate exposure of children to that material. This thread is a public admission that he deliberately placed indecent material on a children's site.
I'm not a big fan of censorship or our indecency laws, but placing that image on a children's site seem a bit of an overreaction. On that might come back and bite.
How is this duplication of effort different from any other competing products? Proprietary competitors are exerting "too much effort" producing *encumbered* clones of encumbered products. It would seem that Open Source makes a bit more sense, as once effort is placed in an unencumbered product the product exists and can be built upon, extended or borrowed from. Is the production of a bunch of products that will compete, fail and then take any innovation with them to their grave *better* than the open collaboration that Open Source allows?
Under the argument you propose, Linux was a pointless exercise because it produced a "free" work-alike to an "existing, known-good, encumbered product". Meanwhile, do you think that if the "effort could be used elsewhere" it would have been used to produce something useful, like say another failed Word knock-off? I don't quite see how proprietary dead ends are better than open source clones, which at least have the virtue of being immortal. (I am doubious of the idea that "more effort" equals "more innovation, as you can see).
No, I don't buy the "open source for everything" mantra that is spouted here. Each development method has its advantages. I doubt that Open Source will be invading the vertical markets any time soon as the user and developer base is too small for the advantages of Open Source to be felt. But when you are talking about things that have become "commodity" such as OS, database, office suites, etc then Open Source makes sense... and that's why they aren't very innovative. Open Source is the ultimate expression of commodity good.
The extreme alternative is for all products to be commercial forever, meaning that large companies continue to cash in on less and less innovative products. Office 2003 had exactly one product than made the upgrade worthwhile to me: Outlook. (I.E. a version without the 2GB file size limit). Products like Open Office keep Microsoft honest by forcing them to try to innovate, but to be honest, how much farther can the basic office suite be pushed? If it turns out the answer is "not much farther in core functionality" then by all means allow the ultimate expression of commodity good be created in that market and start to succeed. If the answer is "all over the place" then I guess we will see just how far office suites can be pushed. Everyone is a winner, either outcome. Discounting the "innovation pressure" than Open Source is putting on the commercial vendors I think understates the value of the ultimate commodity good. No, the products are not usually massively innovative, but they force the commercial vedors to be so or perish.
So where *does* one maintain session when cookies and Javascript are blocked? I guess one could force every page navigation to be a form post, but the single target per form would lead to some pretty stupid looking design.
"That's a good thing." Nah, if google has figured out how not to infinite recurse, surely Microsoft can figure it out as well instead of demanding the Internet change in structure to suit its whims.
Note that I agree that where possible session state shouldn't be in the URL, but for maximum compatibility and flexibility while adhering to standards we do maintain session state (simply a ID and security hash to DB state) on the URL. I guess I could turn customers away, but that seems pointless when I don't have to. (And no, Microsoft's algorithmic failure is not equal to "I have to"... robots.txt works just fine until they figure it out.)
Board Game Geek is a site with a focus on "German Style" or "Designer" games. The "perfect" design (to this subgroup of gamers) is one that minimizes luck without removing it: a middle ground between the abstract and luck-fest.
They like fun "bits" (thus Zombies!!! position is high because, hey, glow in the dark zombies) and they dislike "classics" because as a group they are looking for something exciting and new.
Ask the "average American" about boardgames and they will probably list "Monopoly, Risk and party games".
Ask the "average BGG member" about boardgames and they will probably list "Settlers, Puerto Rico and [insert oddball game you have little chance of ever playing here]".
Ask the "average consim (wargame) player" about boardgames and you will get a list of dusty titles with lots of cardboard counters.
The "vote-rigging" isn't really that: it is a reflection of the type of games that the community formed around. To say it is vote rigging is like saying that the ratings of films in a independent film festival must be rigged because [mega hollywould blockbuster X] didn't win.
I would agree that being an "after though" isn't wise... but I have watched many people do really stupid things like "I want this to run as fast as possible so I will cache all my data close to me in objects" only to watch the server thrash pages so hard that it was useless. I have watched the other extreme as well happen: "Let's just hit the DB when I need data" and watched poorly thought our queries bring the system to its knees.
For every algorithm there are trade offs. The most common are memory vs time and some people even think about those. Forgetting that they have to push the data down a narrow network channel which they just been saturated or being unaware of the impact on the disk array of the "clever" access patterns their algorithm creates are common things people forget. Assuming they though through the first part.
Personally, I would prefer to think about these implication and then choose a middle of the road, easy to understand implementation. If testing (please note: not slapping your assumptions into production based on your guesswork, but testing in controlled load test environments) shows that we have made performance errors, only then do we swap in harder to understand algorithms, caching mechanisms and other complexity inducing methods. I would say that 10% of our code has been refactored based on such considerations.
Since our programs are web based and we can swap our underlying mechanisms in a day if necessary, perhaps that gives us more flexibility. Perhaps also because we build business systems where "finding that out at the start of programming" is an absurd thing to say, as regulations changes and business stake holder changes mean that anything we do today is likely to be ripped out in a month or a year. Premature optimization seems foolish in the fact of the reality on the ground: "premature expecting to know what this module will *actually* do" in the real world. I would say that 50% of our code has been refactored (over the course of the five years in business) based on business considerations.
Some days I wish I was writing code for some well defined arena that didn't have stakeholders defining the requirements, but some constraints that remained stable through the hirings and firings and mood swings of the clients. That isn't my world.
So, which "performance" are we optimizing for? Memory footprint? Disk access? CPU utilization? Network utilization?
It turns out you rarely know which will bite your face off until you get a representative data set running. If you made the wrong choice, you probably made things *worse* than if you had opted for working code that could be re-factored from "easy to read" to "mostly easy to read and performs where it counts".
When you are working on server based solutions that will be hit hard, all of those could be your bottleneck: or none.
Actually, the company did proceed with a suit and I had to file for discovery to get a third party tech to discover who owned the files on the drive that caused the problem. The suit was withdrawn upon discovery. Companies react adversly to $13,000 + phone bills with no explanation, which I can understand, to an extent. The weasle who tried to blame me was the companies nominal "administrator", and thus had some credibility with the company. He was fortunately cluesless enough to not cover the tracks that were present in the NTFS permission data on the backups from the time the dialer was active.
Having for a long time intended to link my Linux box to my home LAN's AD, this was just the ticket to try it. Overall things went well, although the instructions completely skip over the actual configuration of the krb5.conf file.
In particular, this is a huge oversite because things don't work as expected. After some googling I discovered that you must specify the domain as MYDOMAIN.LOCAL, all caps. This must be done in several places, otherwise it throws cryptic errors.
With that one proviso in place, I would say the rest of the instructions were sufficient for me to figure it out in 30 minutes. Both directions authenticate properly.
I have considered doing this (and sometimes feel like I am when it comes to family and friends). However, I was advised that the insurance risks to my company were too great, even if I did the work as an individual. Yes, gotta love the good old US legal system, where simply advising someone on how to use their computers makes you exposed to lawsuits for all the unrelated stuff that happens to them afterwords. Since this situation has happened to me in the business world (employee downloads porn dialer on a machine I didn't even touch and then accuses me when it is discovered) already, it's a risk I would prefer not to take. In that case, NTFS was able to help me show the owner that the account used to download the dialer was not the administrative account, but this bozo's account, but I may not always be so lucky.
While I believe that knowing several languages will allow acquisition of additional languages of the same style, procedural programming does little to prepare people for the mental shift to functional/logic/declarative languages. The converse is probably true (I just don't know of anyone who didn't know procedural to start with).
It is for this reason I prefer to hire people with experience with at least one of the languages of these types: it broadens the mind and some of the concepts are very applicable in modern programs, just not well supported out of the box. For example, we have a declarative computation engine in our product. Spell out the formulas you want and we figure out what order to apply them to input data (using similar logic as a spreadsheet uses to determine execution order). This means that even novice users can specify fairly complex computations, as they don't have to worry about side effects, execution order, etc. Just inputs, functions and outputs. Most of the programmers (read: unaware of an alternative to procedural programming) wanted to give our users a scripting language, but it turned out over the years that the declarative method was far more elegant and usable. Since the preprocessor outputs standard procedural code that is used to actually execute the results, we don't even pay a penalty in performance for the declarative style.
The irony here is that most of the people I interviewed who knew how to use both types of languages well were self taught. Schools teach the functional stuff, but do it in a "oh, and the mad theoretical people use this nonsense" manner where the students seem repelled by the idea of actually having to *code* declaratively. Meanwhile, our untrained (in the computer sciences) users love the declarative coding.
So you would prefer a malware infested machine to be hooked to a network than to use a USB stick??? I'm not following how that is a good idea.
I will second this: if you are looking for a bugtracker that works well and is a breeze to install, Mantis is it. I personally use it on LAMP platforms, but I have installed it on Windows on an experimental basis and it worked fine.
Well, with art production values apparently in line with the overall layout values, I guess I'm lucky I skipped on this one. :)
I'm a bit confused the the focus of this review. From what I gather, this is an art book. Yet very little of the review discusses the art within. Typos, grammatical errors and orphan control are not what I usually rate my art books on (although layout is important and shouldn't be this shabby). I found the review 100% helpful in regards to the quality of layout and only 20% help in regards to contents, except when it was misspelled.
It is almost like this review needed to be edited by a third party editor...
I'll take it that your work situation isn't very good. If you are being assigned to work at 100% workload you have a poor project manager. Actual working time varies from company to company: we have very few meetings, but we have overhead like anyone else and therefore don't expect 40 hours of assigned work to be completed in 40 working hours.
Unless someone is totally unaware of reality, they should be using the "Working Time" defaults in the scheduling software to exclude meetings and other known overhead. Then for each employee the "Resource Availability" should be set to whatever percentage is reasonable for your environment (which sounds pretty low in your environment: a sign of structural disfunction, not scheduling per-se). Once you do that, if the scheduled hours from the team is reasonable, the schedule will be reasonable. Reasonable doesn't mean perfect, but the goal is for your team to be able to have an average completion time that is within the ballpark of the estimates. Likewise, the amount of working time vs overhead is checked to ensure that extra overhead isn't creeping into the system. That's about all you can do (other than feedback loops on the estimates) to ensure a reasonable schedule.
Regarding "was-supposed-to-be-working" code, we charge those incidents back to the original developer of that change (good CVS commit logs and the schedule make it pretty clear who owned a change). Our estimates include development *and* testing time, which throws a lot of programmers at first because they think they can just toss something together and throw it over the wall. It doesn't take long for the time estimates to start assimilating that requirement though: the programmer will consistently underperform estimates that were made, and after a couple of weeks we will come to a new agreement on estimates. The person who has to make the emergency fix obviously isn't penalized for such an emergency, but more than one in a blue moon of that nature is another sign of a disfunctional organizational system... the owner of repeated emergency repair inducing code won't be with us long unless *that* changes. (Test driven development really helps stop much of that in its tracks).
As the project manager, you will be responsible for the time the project takes to actually build, and reconciling the differences between what the team can actually do and management's desires for instant turnaround.
The only way to resolve these two conflicting forces is with good hard data to back up any timetables you are presenting. The only way to achieve *that* is to break the work to be done down into the smallest chunks you can pallet. I personally refuse any time estimate larger than three days and look skeptically at those of one or two days.
The reason for that is that any estimate of "oh, that will take a week" implies that the task has not yet been broken down far enough to actually understand the task. It is perfectly acceptable to say: "yes, but what is that week going to be used doing". Usually you will get "well, I need to revise A, B and C". At that point you can say "give me an estimate of A, B and C separately".
Don't be surprised when the response is "but A B and C all require revising D". You have now achived forward progress understanding your work breakdown structure. D is a prerequisate for A, B and C, and yet your original estimate of one week may not have even considered that. Once you have tasks of "a couple of hours" and "half a day" you can be fairly sure that you have a handle on the tasks. But more importantly, if a task takes longer than it should, at the end of the day you can say "hey, I notice task D isn't done: what's up with that". It may turn out that D is an iceberg task... and you would have found that out a week later under the original estimate, now you have only spent a day learning that you have an iceberg and need to revise the schedule even more.
The truth of the matter is that all programmers are optimists when confronted with a simply stated task and they will give overly optimistic time estimates until you actually start analysis of the problem. Creating a work breakdown structure that is fine grained (don't go completely overboard: "a couple of hours" is a good target point) will help you create your broad schedule with more realistic targets.
Management will appreciate being able to back up your schedules with a fine grain detail (even if they ignore the detail itself) and your programmers will appreciate not being hit with iceberg tasks that kill the apparent productivity. Don't be suprised if the total of the fine grain schedule exceeds the initial WAG (wildly accurate guess) by a factor of 2 or more. Front loading the analysis usually uncovers many things that were ignored.
Yes, I'm aware of that clause... however it used to mean "we can withdraw support from a product at any time and you can't do anything about it". For example, when a company end of lives a product, that clause prevents them from being sued for lack of support, updates, etc. However, I can pull out my old CDs and install any patched I downloaded and have the last version released of almost any package.
Except those with activation. Because... there is nobody to activate it. Now if you are a corporation and buy activation based software, you can hammer out a end of life agreement (that is the foundation of contract law: two parties reaching an agreement). As an individual with no negotiation available on the supposed "contract", the EULA enforces an unconscionable provision.
It will be interesting once a case actually reaches the courts where many consumers are jacked by the untimely death of a company. Something of the magnatude of Intuit going under suddenly leaving all those with Quicken locked out of their financial data. Somehow I don't see the courts buying "we can just up and lock people out" even if the EULA says they can.
I would agree with many of your statements. I have not bought Half Life 2 and will not buy it because of a prior experience with activation based gaming. I dropped a small amount to Real when they came out with Real Arcade. I downloaded a small number of games and played them off and on. Finally, the computer failed and I replaced it. Tossed the old drive in the new machine and found the games didn't work. Called Real and they told me to get bent (short form). Turned out that the games are hardware locked and replacing your hardware invalidated all game purchases. (This was near the product launch, have no idea if it is still so daconian.
So yes: you "bought" a license. Live with the terms. And vote with your wallet, hopefully *before* you get burned.
In my opinion, however, the posters statement you quote is a true statement. You didn't buy anything, you *rented* it, and there is a big difference between buying and renting. People should be aware of that difference. A sticker on the box of HL2 that says "you can play this game until: (we go out of business|decide you can't|want to force an upgraded version on you)" would make that a bit more clear.
Then why do you stay? If this site is "BSD Dying" then get off the URL and save bandwidth for those who still find it amusing. But complaining about "paid subscriptions" when you yourself don't have one (and thus get the content, however flawed you feel it is, for free) is sanctimonious nonesense.
I don't see a subscriber icon on your name: so how does asking for money for subscriptions impact *your* life?
Bravo! Excellent comment: I have always wondered about those who think that the story of Christ has to be "right" when those who believe in him are a minority on the planet. Every other religion makes the same claim to being "right". If this is a popularity contest, Hinduism and Islam look pretty strong. If this isn't a popularity contest, then on what basis should I choose? That the "story sounds good". All religions make an effort to sound good. "That I grew up seeped in these traditions" is what most Christians base their "faith" on, which is as illogical as they come, as that is the same reason that other large religious populations exist and remain stable.
I have always seen religions as the ultimate expression of memes: those that exist today have strong survival traits. The are resistant to outside attack (either by logic or other religious thought patterns), highly transmittable to those without a strong of a meme in place (either by promise of benefits of threats of penalties) and mutable to current conditions (such as the adoption of local custom as part of the base religion to attract converts).
"I'm not afraid of homosexuals any more than I'm afraid of deaf people who want deafness recognized as a normal variation."
What the heck does that mean: that you are unafraid of homosexuals (in which case your concerns about sex lives should end about there) or you are afraid of deaf people who would like to live a somewhat normal life? Because, that sentence combined with the prior sure makes it seem like the latter, which scares the heck out of me. You believe that homosexuality being a normal variation is wrong. Then you draw a parallel between deafness and homosexuality and conclude you have the same feelings about both. Wow. Just wow. Don't even both to respond, I just added you to my "hateful irrationals" list.
That article does point out a major problem with the majority of adventure games. I don't think we will see many more mainstream adventure games of the traditional mold because of that bizarre "logic" that evolved around the adventure game community.
The best part of traditional adventure games were story and the triumph of solving a puzzle. The former (story) could be the part of so many more games than it currently is. One of the reasons I loved Half-Life was that there was a fun storytelling mechanism that never removed the player from the game. The latter (problem solving) is found in only a rudimentary form in most modern games (find key, locks magically open). Illogic puzzles are out, story is in: I don't morn that state, except the lack of more Monkey Island goodness.
Ignoring the creationist throwaway comment, you have a point. However, the reason that iterative design has had a rise recently is the recognition that traditional design has failed to provide business value in many cases. I work in an iterative design methodology, but it is tempered with as much forward though as I can give a product. The realization that I think has to be made is that no person or team can forsee all requirements and therefor even the obstinately linear design will be iterative, and often the processes are not in place to handle the required iterations when the mindset is *to* linear.
I have created many large systems for companies. I have also created many small systems. The reality on the ground is most large systems *grow* out of small systems. Yes, I try to think ahead and plan for growth, but you never know which systems *will* grow and which will be one off throwaways. Often the systems that business people are gunning for "big picture" implementations are the ones that get tossed the fastest. Meanwhile, some of the systems that would have seemed to be total tangents have grown into core systems.
Business reality is composed of one core truth: change or die. Grand designs of linear nature are not good for handling that environment. Now there may be some areas where grand design is possible (I would think that more core science/math based software, or well understood problems like operating systems and programming languages would be good counter examples) but in the realm I work in, where managers change direction on a daily basis, integration requirements change weekly and customer directions change monthly, I would challenge any "grand design" to stand and deliver what iterative design can.