Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Thinking about student projects to advise; I'm an OK C develepor and C++ developer/architect.
Not done much Linux kernel development beyond "write your first module".
The thing I want to rudimentarily implement (before advising students doing it properly as a team project) is:
Take existing block device, say /dev/sda
add second block device, say /dev/fec0, which implements wrapper around first, providing error-correction on read and writing data + error coding information on write
This implies that the size of fec0 is smaller than that of sda. Also, note that this is somewhat different to the RAID5 approach, as there's no split of parity data to secondary data groups or similar.
Now, I'm trying to get an overview of how to do this. It's clear that it will be necessary, aside from implementing the block device interface itself, to implement a control interface to define things like "use /dev/sda to create fec0", "shut down fec0".
The questions that arise are:
Is there a preferred framework to integrate this into? Goal is finding the sensible place to put this. To mind come:
dmraid and
lvm2, or
just a plain block device driver
How to implement control interfacing?
Specific ioctls?
/sys/* pseudofile interface?
framework-specific ways?
For the first part of your question, I'd suggest you have two choices: the block subsystem or the md (multiple device) subsystem. I think the most useful thing I could do would be to point you in the direction of some references so you can decide what fits best. If you want to account for logical volumes then see here for the lvm-raid man page which sits in both the md and dm subsystems. If you just want to restrict yourself to RAID functionality, then see here for the md driver man page. But if you want to keep it simple and just make a wrapper over a simple block device, perhaps emulating some aspects of lvm and raid, then add a driver to the block subsystem.
Your choice would affect the second part of your question, too. Single block devices commonly provide lots of ioctls; md drivers make a lot of use of the sysfs interface. Hope that's helpful.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Excuse me for the title a little provocative.I'll take an example. Suppose you need to write a program to build a car. Here's a test program:
public void testCarBuilder()
{
expectedCar=someCar;
actualCar=carFactory.build(bigWhell, yellowBodyCar);
assertEqual(expectedCar, actualCar);
}
To know that to build a car, we need a function that will have the wheels and the carBody as parameter, it should at least have made an analysis of the program. This analysis can be done in natural language, UML or even directly write in the programming language!. We can write this analysis on a piece of paper, leaving it in our brain, or in writing to a file.
Analysis is already a skeleton of a program! So it was always at least one program skeleton write before the test!
Say that development task starts by writing tests is sybyllin, there is always a first skeleton program ( that we can call analysis) to write before. Unless someone shows me how the opposite may be possible.
Of ccourse some people write a test first.
In fact, you just wrote a test first in the question.
Your test has possibly then told you the code you need to write next, but you have discovered that after you wrote the test in the question.
I interpret your question as if you want to know how the design emerges when doing TDD.
In order to write a test you must define some boundary/surface/facade that the test should interact with. This design activity is done up front. The design that grows and changes is the one that is on the other side of that test boundary.
In your (trivial) example, the design that the tests help you discover is the one inside the carFactory. That's not very helpful, so I would say that your test is not that good.
There are different school within TDD. The one I practise advocate that you test from the outside and in. You choose a test boundary that is as close as possible to the system boundary. For instance, you let your test simulate button clicks in the user interface. When doing this, you are free to make changes to the design of the whole system on the other side of that button click.
In your example, why do you want to create a car? What did the user do to trigger this code, and how can the user tell that whatever she wanted to accomplish worked? That's what you should have in your test.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
After fighting several versions of the CoreKeyGen created by some "minamoto" guy, a new version has appeared. This version is particularly sophisticated and seems to modify the actual binary itself, using a dylib known as libbassmod.dylib (this is in the keygen's Mac OS folder).
Has anyone ever come across this & can give me advice on how to stop it?
If so, how can I stop the keygen? it seems like the library can see what calls my app makes and stop them somehow, I'm not too sure.
I doubt that the "Minamoto" here is the real guy you are looking for, maybe just someone wanted to making fun of you. People in the scene won't have the time to read the post here, nor reply under their real nick.
Back to your questions, libbassmod.dylib is used for audio module playback. It's often used in windows key generaters by the Scene to play audio module formats such as XM, IT, S3M, MOD, MTM, UMX. more info you can read up here:
http://www.un4seen.com/
And about the idea of fighting them or making fun of them in your blog, IMO it will only bring you troubles(Espicially some groups like this one, CORE(which stands for "Challenge Of Reverse Engineering"), google for it if you want to know more about it).
Enough said, if I were you, I'd put my time on making my applications better instead of coding protections. That's the right and only way to get more customers(And believe me they hate software protections). Those who use cracks will never buy anything from you(Just see all those thinsg on MSJ), they use the cracked version of your application was just because they can use it for free, so actually you lose nothing.
libbassmod.dylib is for the background music playback...
What? A keygen usually means someone reverse engineered your key verification algorithm to produce their own algorithm that satisfies yours. There is nothing you can do to stop this, except use PKI or some variant of a whitelist of keys. Even then, they can just patch your program. If you want to know what the keygen is doing, you need to dissassemble it with a dissassembler such as Ollydbg, IDA Pro, etc, it should be fairly simple as keygens are tiny programs, although it's probably a waste of time.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
I've seen a number of question's closed as "Not programming related" (e.g. https://stackoverflow.com/questions/397854/what-process-accesses-my-hdd)
I understand that their's several alternative site (stackoverflow) themed-forums and to attempt keep site question's to a minimum also some may argue that this is too subjective, o well, I got madly flamed for my first answer, so here's my first question, I'll try to frame it in a psudo-contextual-basis (jepordy style) to keep some regulator's at bay...
Is it not fair to #include UNIX systems's level discussion in the same realm as programming? One of the most usefull UNIX tools I've ever used, strace/trus/par, is based around system call information and reporting, other tools like ltrace can do similar things for libararies...
System admin, I agree is not for this forum, like "How to I make qmail do X?", but is "My smtp virus scanner is not fast enough, based on dnotify?" (answer) "Hey, use inotify", so easy to discreminate? The latter may either be shell or linux kernel system call's.
I am not much of one for standards (read one too many lately), I'm adding a tag on POSIX "command language", to shift some focus on idenitfying some definative info.
Systems level interaction being somewhat of a programming-interface(API)/user-interface(shell) duality (perticularly for UNIX).
If the context of an inquisitor be primarially interface based and it is an easy quarry (or even typical) to solution an exclusivly programming/API responce, to help man and machiene alike, why require a domain change (body of knowledge or URL domain;)?
I'm sorry, I don't understand the distinction you appear to be trying to draw between UNIX and Windows. As someone who uses and programs both of them, the distinction about whether a call to a kernel service is in a library or not seems unimportant. The distinction is - is the call made in a programming context? For example, questions about the UNIX cat command do not, I suggest, belong here, whereas questions about the UNIX read() system call, which cat must use at some level, do.
Oh, and there is no "tight integration" between the kernel and the shell.
Is it not fair to #include UNIX systems's level discussion in the same realm as programming? One of the most usefull UNIX tools I've ever used, strace/trus/par, is based around system call information and reporting, other tools like ltrace can do similar things for libararies...
Discussion of debugging tools is perfectly valid on SO, IMO. I've not seen a debugging tools question closed.
So if the closed question you reference had been 'how do I find what processes are touching files for debugging my program', then I imagine it wouldn't have been closed. But it appeared to be 'how do I find what processes are touching files to improve the ambience of my bedroom', which isn't programming related.
Sysadmin questions belong elsewhere. Bash programming is programming related, system utilities aren't. It's just the same as 'how do I make Word format my document in three columns' isn't programming related, but 'how do I program a VB script to format my Word document' is.
I think if you asked the same question today it would also be closed. But rather than "not programming related", it would be "belongs on server fault".
If your question had been, I want to trace the files my program touches, i.e. specifcally related to development work, then it would be marginal.
System admin, I agree is not for this
forum, like "How to I make qmail do
X?", but is "My smtp virus scanner is
not fast enough, based on dnotify?"
(answer) "Hey, use inotify", so easy
to discreminate? The latter may either
be shell or linux kernel system
call's.
We don't need to discriminate. If someone is writing a smtp virus scanner, that is a programming task, and questions about how to do it are programming questions. Then it doesn't matter if it is written in bash, assembly or C++ or Whitespace.
On the other hand, asking "how do I see which processes are running on Unix?" is not a programming question. Yes, the answer will be to use a command which is basically a wrapper around a system call, and so what? The MS Word "save file" dialog is a wrapper around a write file system call too. That doesn't make it programming-related.
I don't really see the problem.
Is it not the case that UNIX systems
related questions are programming
questions? If not, where is the
boundry between a
programming/scripting language and
user interface?
The boundary is here: "Is the question made in a programming context?"
A end-user asking how to use some Unix command is not a programming question. But a programmer asking how to make his program do something on Unix, is programming-related.
It doesn't matter that the shell command and the system call are basically identical. If it is invoked from a programming context, it is programming-related. Otherwise it is not. We can even make the same distinction on Windows. If I ask "How should I call CreateFile from my Python program", that is clearly programming-related.
But "The program I was running crashed, and gave me an error message saying CreateFile failed. What does that mean?" is not programming-related.
One is asked from a programming context, the other simply happens to include the name of a system call.
If you're in doubt, here's Wikipedia's definition of "programming":
Computer programming (often shortened
to programming or coding) is the
process of writing, testing,
debugging/troubleshooting, and
maintaining the source code of
computer programs
That seems pretty clear to me. Are you reading/writing source code? If not, it's hardly programming. Being the user of a utility that was created through programming is enough.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
We are developing a desktop application.We are writing tutorials for users in a wiki.I was looking for some guidance ..good practices when writing such tutorials.
regards
I think some basic rules are ok
include as many screenshots as you can
don't use too much technical wording
structure your pages/documents that it is easy to navigate inside
don't make the user looks stupid, i.e. way of writing that would say the user is not capable of doing anything
Also it could be a good idea if you make your wiki and ask one typical user to review it with you. Getting the opinion of the user would probably show you million of things you have forgotten.
Have a FAQ
Tips and Tricks Section.
Have short videos about "How to..."
A few tips for technical documents:
1- Assume everyone reading the document is the dumbest person you've ever met who has never seen a computer in their entire life.
2- Don't skip a single step. Even if it's clicking a well-known button, etc. If your instruction doesn't start with "click" or "type", it's not granular enough.
3- There are never too many screenshots... unless you can't read the text between them, or fail to notice it entirely. Leave enough spaces between screenshots and text, and make the text one size larger if need be.
4- Do it yourself, multiple times. Make others follow your directions. Make your grandmother follow them. If she can, your manager probably can. Maybe.
Figure out the key features that users will use most often and provide a cheat sheat. Download any one refcards from dzone.com as an example.
I think the best tutorials are those that guide the students in an incremental, step-wise manner. Clearly describe prerequisites at the top and tell the readers 1, 2, 3 this is what you have to do.
Choose your tasks thoughtfully (and stick to them). Each tutorial should cover a single task and stay focused on the goal throughout, with only the briefest digressions to introduce new terms or concepts. Start with the very first step a user needs to take to do something useful with the software. With a well designed app, a sequence of introductory tutorials is likely to start with a very short, simple one ("Creating a New Project") and proceed through intermediate ("Importing INTERCAL-72 Files") to advanced topics ("Customizing the Compiler Toolchain") so that the tutorials become more involved as the user becomes more involved with the app.
Use numbered lists. Describe specific procedures that can be followed by anyone who can read.
Use consistent styles for program and interaction elements, like bold text for buttons and menu items and monospace fonts for user input. The specific styles you choose matter less than their consistent application. If we're talking Windows apps, the Microsoft Manual of Style for Technical Publications might come in handy.
Verify your procedures relentlessly. If a user needs a tutorial to figure out how to use the application, she's probably already frustrated. If she follows it to the letter and it doesn't work, everyone's a lot worse off, including you and your support rep.
Use screenshots as signposts. Include one screenshot of each window and dialog box referenced by the procedure. Don't label them or otherwise doll them up. They're there to provide visual reinforcement that the user is following the procedure correctly and getting to the right places.
Respect different learning styles. Keep in mind that most people are visual and/or auditory learners, so text isn't the best way to reach them. In practice, that means screenshot videos with voiceover. The written tutorial is the script.
make sure your app is intuitive first. then when your sure it is, make it more intuitive.
see :
http://www.discoapp.com/
http://www.utorrent.com/
http://handbrake.fr/
http://www.nethack.org/
dont see:
http://www.adobe.com/
Windows songsmith
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm building Desktop Software for over 10 years now, mostly it's simple Data-Input Software. My problem is, it's always looking the same: A Treeview on the Left and a lot of Text/Data Fields to the right, depending on the type of data currently is worked on. Are there any fresh ideas how such software nowadays should look like?
For further clarification:
It's very hierarchical data, mostly for electronic devices. There are elements of data which provide static settings for the device and there are parts which describe some sort of 'Program' for the device. There are a lot (more than 30) of different input masks. Of course i use combo boxes and Up/Down Entry Fields.
Having all of your software look the same thing is a good thing. One of the best ways to make it easy for people to use your software is to make it look exactly the same as other software your users already know how to use.
There are basically two common strategies for how to handle entry of a lot of data. The first is to have lots of data entry fields on one page. The next is to have only a few data entry fields but a lot of pages in a sort of wizard-style interface. Expert users find the latter much slower to use, as do users who are entering data over and over again. However, the wizard style interface is less confusing for newer users since it offers fewer elements at once and tends to provide more detail on them.
I do suggest replacing as many text fields as possible with auto-complete-based combo-boxes. This allows users to enter data exactly the same as with text-boxes, but also allows users to save typing by hitting the down key to scroll through choices after typing part of the data in.
Providing more detail on what data is being entered would probably yield more specific answers.
I'd also answer with a question, which is to ask what your motivation for considering a change is? Like the other posters, I'd agree that there is some value in consistency, but there's also a strong value in not ignoring niggles-in-the-back-of-the-mind feelings you have. Maybe you have a sense that your users aren't as productive as you'd like them to be, or you've heard feedback to that effect from your customers, or you're just looking to add some innovation for your own interest. Scratching itches is a good trait in a developer, in my view.
One thing I'd advocate would be a detailed user study. How much do you know about what your users do with the interfaces you create? Do you know the key tasks, the overall workflow? Would you know if one task regularly consumed 60% of your users' time, or if there was a task that was only performed once a month? Getting a good sense of what the users actually do (and not what they say they do) is a great place to start thinking about what changes might be worthwhile, especially if you can refactor the task to get a qualitatively different user experience.
A couple of specific alternative designs you might like to include in re-visioning the UI might be be facet browsing (works well for searching and exploring in hierarchies), or building a database of defaults / past responses so that text boxes can use predictive completion. However, I think my starting point would be the user study.
Ian
If it works...
Depending on what you've got happening with the data (that is, is it hierarchical, or fairly flat), you might want to try a tab-based metaphor, or perhaps the "Outlook-style", with a sidebar showing the sections of an application. One other notion I've played with lately is the "Object desktop" that I first saw proposed by Scott Ambler (Building Object Applications That Work). In this, you can display collections of items, or the user can "peel off" individual records for easy access.
Your information is not enough to really suggest you an interface alternative. However, may I answer your question with a question? Why do you think you have to change it? Has your customer complained? If not, it looks like your customer is happy with the way the software works right now, thus I wouldn't change it. If your customer complains about it, he'll most likely not just say "It's bad", he will say "Why can't it look like ..." and this will give you an idea how to change it.
I once had to re-design a very outdated goods management system. The old one was written for a now dead database system, still running in MS-DOS. The customer suggested I should create a prototype how this re-implementation might look like and then he'll decide if I get that job or not. I replaced the old, dead database with a modern MySQL database, I replaced the problematic shared peer access with a client server approach and I chose to rewrite the UI in Java, since different OSes were used and this had the smallest porting costs. So far the concept seemed good, the customer liked it. However, when he asked his employees what they think about it, they asked "So far it's great, but we have one question: Why doesn't it look like the old one?". Actually, it turned out that even with all the modern technologies, they wanted the interface to exactly look and being operated like the old one. So I had to re-build a 1986 usability nightmare MS-DOS UI in Java, because no other UI was accepted.
For me it is more about a clean, usable, logical design than anything else. If your program makes sense to the user, isn't clunky and works as advertised, then everything else UI related is essentially just like painting the house. I've sometimes rolled out a new version of a program with essentially the same controls that are skinned differently.
There's a reason that you've probably chosen the tree view - because it probably makes really good sense to do so. There are different containers and controls available in the various UI libraries, depending on the language, but I tend to stick with the familiar because the user probably gets how a tree control works and how a combobox works.
A user interface needs to be usable, just don't do the misstake to change to something working to something fancy-schmancy just because it looks better (been down that road)...
Make sure that added
widgets/controls really add a business value
Make sure that the added
widgets/controls do not mess up your
architecture (too much) and makes
the application harder to
manage/maintain
Try to keep platform standards on
how to do things (for example the Vista ux guidelines)
:)
//W