Related
I study on entropy source using the Random number generator.
So I want to see a kernel source code.
However, I don't exactly know this, and i know this is not known.
Would you tell me about this?
Thanks.
Windows Driver Foundation forbids such actions due to obvious malicious stuff that can happen if the source code leaks
If you have access to enough information about the device you're using, you could try writing a skeleton driver. However, some TRNGs have open-source driver code, so if yours is one of them, you could download that. If those aren't options in your case, unfortunately proprietary software companies do not generally share their source code (though Microsoft does share their code with certain CS departments in academia - if you're affiliated with one, you could look into that).
Many applications are let down by the quality of the 'writing' in their user interfaces: typically, poor spelling, grammar, inconsistent tone, and worse yet, "humour" are the usual offenders.
Are there good resources that can help developers to write UI messages that give a professional and positive impression to your customers, even when your code's going to hell in a handcart?
Thanks, all — Some great resources here, so I will CW this question. I'm accepting Adam Sill's answer because it's the one that (as a developer of desktop apps) I found most pertinent.
Since XP, I've been a fan of the Windows UX Guidelines sections that cover how to properly structure text (how to ask questions, how to make assertions in dialogs, etc).
http://msdn.microsoft.com/en-us/library/aa974176.aspx
http://msdn.microsoft.com/en-us/library/aa974175.aspx
Read The Elements of Style. Then re-read it.
Also, anytime you are working with a program or website make a conscious effort to notice how they choose to do their writing. Imitate those you like.
The resources found at Writing for the Web might be useful to you.
The best tool for this is called "primary education". Many developers seem to have missed this, and I don't know how to fix that problem.
Also, this may be a British thing, but I think you mean "humor" and "going to Hell in a handbasket". :)
This book has a lot of good advice:
GUI Bloopers 2.0
Short version:
Be consistent throughout your application or app suite. Don't call the same feature two different names, even if they're in different dialogs, etc. Develop a product lexicon that everyone references.
Use the same terms that people who use your software use (i.e. users don't refer to themselves as users).
Don't call two different things by the same name.
Put all of the messages displayed to the user in a central place (i.e. a resources file of some kind). This makes it easy to review all of the messages for spelling, tone, consistency, and whatever else you want to check.
Usability test your software to see if the messages make sense and people can use your software easily. If they can't, change the resources file and test it again.
I would suggest showing your UI to as many people as you can--preferably people who read a lot (Just because reading does wonders for your grammar and vocabulary).
Getting something out that people can examine, however, is awesome--even if it's just a demo of the GUI.
If you work at a company, get to know your QA and Tech Support people. They are usually really wonderful once they understand what you are trying to do--they will review your UI, give you input on text and usability as well as possibly new requirements nobody in engineering would come up with.
If you work on your own, try to find a potential customer or two to review your UI. Ask them to pay attention to the text...
The more eyes, the better. You might even ask your parents, wife or other family. What can it hurt?
Get your application's texts proofread by someone who does just that for a living. Then the UI walked through by someone who does usability for a living. Neither of these two people should have been involved in the development.
It's the only way to make sure.
I have inherited a project from a client, who believes he has all the source code, but unfortunately this particular VB6 application used a bunch of custom controls that the original programmer will not give up (he may in fact have purchased the licenses himself, so he may be right in not turning them over, on the other hand since he has been cut-off from the project there may be a bit of spite involved - I have no idea and it doesn't really matter.)
Anyway, the project uses the following controls:
PVOutlookBar.ocx
PVList.ocx
PVCombo.ocx
PVXplore8.ocx
PVDateEdit.ocx
PVTime.ocx
PVDt80.ocx
and as far as I can tell they were from a company called Protoview which was bought up by Infragistics...and none of these controls are supported anymore, though they can be purchased at full price.
My client is very reluctant to spend over $1000 to get his hands on these controls, especially since
1) they are no longer supported at all by the vendor
2) we have no guarantee that if these are purchased that it will work (i.e. maybe there is a lot of other stuff missing too).
3) there are no refunds, even if we bought the wrong stuff...
4) we only need to get it running enough to start the port to a more updated language, either vb.net or C# (and thus would need to possibly buy the controls again).
My question is, is it legal if someone had these controls, and was no longer using them, to sell them? I would assume that the if you were no longer using a piece of software, you could transfer the license (the hope would be to find someone who has them lying around and would be willing to part with them for a lot less than buying the new).
Anyone know any sources for buying "old" software, especially controls such as these? I found Retrosoftware website (no longer operational) but they don't have any of the stuff I need.
Thanks.
I Am Not A Lawyer, but I think the legality of transferring a license depends on the original license terms for the controls used by ProtoView. Some licenses allow it and some explicitly forbid it.
Certainly the license agreement Infragistics is currently using does not allow you to transfer the license.
I want to add a "Community" section (Bulletin Board) to my website so everyone can communicate, but I don't know what I'm doing.
How would I go about adding this and which one offers the most documentation and support?
Whatever you do, make certain that you read the instructions on configuring your discussion software to protect you and your community for the worst parts of the internet: spam, spoofing, and abuse.
Make certain that you immediately change the admin password from the one that comes with the installation.
If you leave your communities wide open to all kinds of posting, harvesting, and general mis-use, you'll spend your days playing whack-a-mole with thousands of idiots. Develop your acceptable use policy, configure your boards to support it, then enforce it.
And if the software you are looking at doesn't support things like e-mail verification, moderation, abuse reporting, anti-spamming controls, etc., just keep looking.
Be prepared to spend time managing your community so that it doesn't become another one of the millions of web forums out there full of off topic posts that drive people away from your website.
I think what you needed is a forum software, there are tones of free and open source ones available on the net. DotNetNuke is a .NET one but can be expensive to host and phpBB is another popular choice and there are a lot of cheap hosting solutions.
is your site based on php/mysql or asp/sql? Chances are if you do not know where to even find tables, that you are not able to what you actually want.
HOWEVER, if it's php/mysql, i recommend Cool Php Scripts book. It covers creating sort of a community forum/message board.
As i said again, you are probably not going to do it alone, at least, without a long frustrating learning curve.
You can always post a job and someone would be more than willing to bid on it at elance or rentacoder or any other site of your choice
Wikipedia has a big honking list of forum software. Pick the one that best matches the programming language(s) you're familiar with, the features you need, etc.
This is what you need.
Edit: They don't offer a hosted version there. You can use this instead. It's hosted on it's own site, free, and doesn't require a download.
I find Vanilla to be a much better forum application that phpBB for reasons of aesthetics as well as extensibility. I have not seen/used it in a situation where many sub-forums were required, so depending on your scope it may not be the right choice, but for small-to-medium sized forums I'd suggest trying it first.
First, you need to choose a forum software that matchs your requirements.
Then, just follow the Installation Guide provided by the software you have choosen.
More information at Forum Software Reviews
My dad always says "Responsibility without Authority is meaningless".
However, I find that as developers, we get stuck in situations all the time where we are:
Responsible for ensuring the software is "bug free", but don't have the authority to implement a bug tracking system
Responsible for hitting project deadlines, but can't influence requirements, quality, or team resources (the three parts of project management)
etc.
Of course there are tons of things you could say to get around this - find a new job, fight with boss, etc....
But what about a technical solution to this problem? That is, what kind of coding things can you do on your own without having to convince a team to correct some of these issues - or what kind of tools can you use to demonstrate why untracked bugs are hurting you, that deadlines are being missed because of quality problems, and how can you use these tools to gain more "authority" without having to be the boss?
***An example - the boss comes to you and says "Why are there so many bugs!!?!?" - most of us would say "We don't have a good system to track them!", but this is usually seen as an excuse in my experience. So what if you could point to some report (managers love reports) and say "See, this is why"?
All you can do is your best, don't feel as if the key to successful software is only in your hands, your part of a team and don't have to be responsible for all.
Obviously you are in a environment that affects negatively your software, but can't change all his behavior so I recommend you start with yours, start working as a team of one with your own bugs, deadlines, requirements, quality and resources don't bother for the rest of the mess, but try to be the best at your work.
Working as a self-directed team of one showing your boss your plans, and reports of your progress, asking for more resources when you need it and showing him how your plans get affected when he give them to you or not.
You can find more advise about this in the PSP and TSP articles of wikipedia
After showing your boss a good work and meeting your own deadlines, surely he will trust you more and let some of your ideas flow to the entire team.
You don't need a bug-tracking system, you need automated tests: unit tests or otherwise. You can set-up automated tests with a Makefile. You can always find paths that are blocked by management, but that doesn't mean there aren't things you can do within the constraints of your job. Of course, the answer could be "find another job". If you can't find another job now, learn some skills so that you can.
The simple answer is -- you can start using the tools yourself.
Improve your own work. If people want you to fix code, tell them to file a bug. Show them how. Make sure they can do it without installing anything. They want a status update? Tell them to check the bug. They ask abou a code change you made? show them how to make a source control history query. or just show them on your box. Start showing them this stuff works.
And when you need the same results from them, demand that they do the legwork. When you can't find the changes in your source control, ask them to start diffing their revisions manually from the backup tapes. Don't do their work, or the work of source control and bug tracking, for them.
And most importantly, when applying this peer pressure, be nice about it. Flies and honey and all.
If they don't get it, you can continue to be the only professional developer in your company or group. Or at least it will help pad your resume: 'experience setting up and instructing others in CVS and FogBugs to improve product quality' and the like.
As for specific tools for showing that untracked bugs are hurting the team's ability to produce quality code, you've got a catch-22 here since you need something to track bugs before you can show their effect. You can't measure what you can't track. So what to do?
As an analogous example, we recently had a guy join our team who felt the way we did code reviews via email was preposterous. So, he found an open source tool, installed it on his box, got a few of our open-minded team members to try it out for a while, then demoed it to our team-lead. Within a few weeks he had the opportunity to demo it to all our teams. The new guy was influencing the whole company. I've heard lots of stories of this guerrilla-style tool adoption.
The trick is identifying who has the authority to make the decision, finding out what they value, and gathering enough evidence that what you want to implement will give them what they value.
For a broader look at how to lead from the middle, or bottom, of an organization, check out John Maxwell's The 360 Degree Leader.
If you want a report about quality and it's impact on productivity - here's the best:
http://itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html
Caper Jones has a few books out and is still showing up at conferences. Outside of a good IDE a developer/IT group needs source code control (VSS, SubVersion, etc ) and issue tracking
If an accountant is asked to produce a set of account without using double entry and don’t balance, no one would expect the accountant to do so.
However double entry has been in standard usage by accountants since about the 13th century.
It will take a long time before we as a profession have standard practise that are so ingrained that on-one will work without them.
So, sorry I expect we will have to face this type of problem for many year to come.
Sorry for not answering your question directly, but...
I feel strongly that the failure you refer to is one of communication, and it's incumbent on us as professionals to develop our communication skills to the point where we are respected enough and trusted enough to leverage the authority we need to improve our working environments and processes the way you suggest.
In short, I don't think there is a technical solution that can solve all the problems created through poor communication in the workplace.
If anything, technology has caused the attrition of direct face-to-face communication.
Sorry, I'm off on a tangent again - feel free to downmod.
Coding only you can only keep your own source files tidy, well commented, keep the bug count low with tests. But you are going to need external tools for tracking progress and bugs (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, a blog, whatever). In these cases the people and the discipline and the good habits and the leadership are the overwhelming force, no software tools and no offert from the individual can win alone.