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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Please take a look at my recent question here: Deadlock with no user code
How can you tell when the debugger is lying to you in this way? Other than, of course, showing that what it is telling you is impossible?
I don't like relying on that since I've seen so many 'impossible' states in a program that were in fact happening due to some subtle or esoteric problem.
Yes, those are pretty wacky stack traces, particularly the 1st one. Hard to theorize how that happened. It doesn't usually get that screwed up unless you debug optimized code.
Which is hint #1, never trust what the debugger tells you when you have to debug release built code. Strongly avoid it, you don't always have the luxury when you need to troubleshoot a deadlock however.
Strong hint #2 is paying attention to the code-flow. The normal one for a blocked thread, bottom to top in the Call Stack window, is yourcode => runtime (msvr120) => winapi layer (kernel32 et al) => native api (ntdll.dll). This is generally the case, there are a few cases where this flow is reversed, callbacks from the OS into your code, like window notification, thread-start (always at the far bottom of the stack for example), I/O completion.
Which is what's wacky, there is no realistic scenario where a low-level native api function like ZwWaitForSingleObject() could ever directly call into the C runtime library. That's bogus, only the top entry (Block) could be accurate. Yes, tough debugging that way.
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 5 years ago.
Improve this question
In a recent meeting with my client, we discovered we missed out on a Detail of User Story, that has already been implemented several iterations before.
The new requirement is not only an additional Feature but changed behaviour.
The original User Story goes like:
"Can View XYZ"
The new request however goes like:
"Can View XYZ but if B then XYZ must look like ABC"
Shall i consider this a Bug or a New User Story, or should i simply reopen the old user Story and edit it to account for the new request?
What is the "best-practice", what are pros and cons of each approach?
Well, since it is a new requirement, treat it as a new feature request. Definitely not a bug.
EDIT: Since it is not clear who missed the detail either you or the customer, you can take both ways. If you forgot about it, then it is your bug. If the customer forgot to tell about it, then it depends. If it is a little fix, you can reopen the old story. If it is much work to be done, make it a new one.
P.S. Does it really matter how you do it? The point is just implement it like the customer asks, regardless of your internal terminology.
(source: oracle-guy.com)
A Bug, a new User Story, reopening the old Story... is that really important? In any case, your customer is asking for a feature that is currently not implemented. So, as long as you can estimate its size and as long as he can prioritize it, it doesn't really matter how you call the way you capture the needs.
So, unless you have to deal with specific contractual constraints, just pick one solution, estimate the size and let the customer prioritize it (personally, I'd create a new user story).
I would edit the old story to document the modification. Otherwise you may have contradictions between the new story and the old one.
This can hardly be considered as a defect (or bug) if the customer changed its mind.
Be pragmatic: estimate it, schedule it and implement it.
I would say this should count as the old story. Your team should report reduced throughput (velocity) because of these changing requirements, especially if the original feature has not already shipped.
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 3 years ago.
Improve this question
I would like to know your experience when you need to take over somebody else's software project - more so when the original software developer has already resigned.
The most success that we've had with that is to "wiki" everything. During the notice period ask the leaving developer to help you document everything in the team/company wiki and see if you can do code reviews with him/her and add comments to the code while doing the reviews that explain sections. Best for the "taking over" developer to write the comments in the code under the supervision of the leaver.
Cases where original devs leaved before handing over the project are always the most interesting: you're stuck with a codebase in an unknown state. What I always find intriguing is how the new devs often do their utmost best to comment on how badly designed the code is: they forget about the constraints the old devs might have been under, the shortcuts they might have been forced to make. The saying is always Old dev == bad dev. What do you people think:
I would even call this out as an official bad practice: bad-mouthing the ones who have been before us.
I try to take as much a pragmatic approach as possible: learn the codebase, wander around a bit. Try to understand the relation between requirements and code, even is there is no clear initial relationship at all. There will always be the "aha moment" when you realise why they did something was done this way or that. If you're still convinced something is implemented the wrong way, do your refactorings if possible. And isolate the pieces of code you cannot change: unit test them by using a mocking framework.
Hail to the maintenance developer.
I once joined a team which has been handed over a pile of steaming crap from outsourcing. The original project - a multimedia content manager based on Java, Struts, Hibernate|Oracle - was well structured (it seems like it was the work of a couple of people, pair programming, wise use of design patterns, some unit testing). Then someone else inherited the project and endlessly copy-pasted features, loosened the business rules, patched, branched until it became a huge spaghetti monster with fine crafted piece of codes like:
List<Stuff> stuff = null;
if (LOG.isDebugEnabled())
{
stuff = findStuff();
LOG.debug("Yeah, I'm a smart guy!");
for (Stuff stu : stuff)
{
LOG.debug("I've got this stuff: " + stu);
}
}
methodThatUsesStuff(stuff);
hidden amongst the other brilliant ingenuity.
I tamed the beast via patient refactoring (extracting methods and classes more of the times), commenting the code from time to time, reorganizing everything till the codebase shrunk by 30%, getting more and more manageable over time.
I had to take over someone else’s code of different degrees of quality on several occasions. Hence the tips:
Make effort to take structured notes of any piece of significant information from minute one: names of stakeholders, business rules, code and document locations etc. It is best to dedicate a fresh spiral notebook, so you could tear pages out if you had to.
Make use of one of the better free indexing and desktop search tools available on the market (Google Desktop Search, MS Windows Search will do). Add all document, e-mail, code locations to it.
Before developing anything do document analysis: find everything you can get you hands on electronically on network and printed out docs, make effort of simply reading it. There is amazingly much of useful information even within unfinished drafts.
Mind map the code, architecture etc as you go.
With lesser documented and maintained systems you inevitably will have moments of despair that are likely to push you into procrastination mode. Especially during your first days or week when amount of new information your mind has to digest is overwhelming. At these times it is nice to have someone to remind you (or just do it yourself) to take it easy, concentrate on important things first and revert to making smaller steps in trying to gain understanding instead of trying to leap forward.
Keep taking notes, making diagrams, drawing rich pictures, mind mapping. It really helps to digest the copious amounts of new information, mostly disorganised.
Hei, good luck!
We actually have a specified set of "Deliverables" that has to be present for us to take over a project.
If we have the chance we try to push in one of our folks within the group developing the project at first. That way we get some firsthand knowledgde before our group takes over the code. (in the line of what #Guy wrote)
That being said, the most important part for me would be:
Some kind og highlevel overview(drawing?) of what the code do.
Easy access to ask questions of the people who actually wrote the code
This for me is alpha omega when taking over code and projects
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