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 10 years ago.
Improve this question
I have a specific problem. I want to sell one of my models, programmed in the R programming language. I want to show the prospective client that there is a lot of advanced work in the code, and there is a lot of it, representing about 700 hours of R&D (around 2000 lines of R code). So, I want to send him the code. To impress him.
However I obviously don't want to disclose the full workings of the code, so I was thinking of garbling every third or fourth line, so that it cannot simply be OCR'd and replicated. I don't want to go down the NDA route, nor is the client adept at programming (wouldn't be able to replicate it himself - though could hire a programmer I guess). I'd also probably garble completely one or two key functions.
How would I do this in Vi / Vim?
Is there any other way of solving my issue that someone could suggest?
Yes I know I could show him the output of the program as the sales pitch, which I have already done, but we're haggling on pricing so a bit of "blinding with science" through a code listing, to see how much work is involved, won't hurt. It is my experience that many non-programmers have no idea of how much work can go into a piece of software.
You should move/repost your question to programmers.stackexchange.com, it seems more fitting.
However, I think that if you are trying to sell something to someone non technical, showing the code won't work. Typing 2000 line of code is not that long. He/She won't be able to gauge the value by reading some incomprehensible symbols.
Rather you should show the added value of your code for his/her business. So get a set of data (potentially from your customer), and extracting/showing relevant information from that set should be more impressive. I should add that the price of your model does not only depend of the work involved, but also from the potential benefits for you customer.
A piece of code is only solving a problem, you can probably sell it from 10$ to 100 millions $ depending on the problem solved.
I fully back the points brought up by Xavier T., but if you still think you need to show some representation of the full body of code to make an impression about the amount of your work, I'd either:
Create a printout with a very small font just to get the structure across (e.g. :set printfont=Courier_h4); obviously, this only works for paper copies, not PDFs.
Obfuscate by replacing all alphabetic letters with x, as in :%substitute/\a/x/g
Related
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 8 years ago.
Improve this question
I have a requirement where my source data is in HDFS, and there is one field which contains skills of the users. Now the source file has all kind of skills attributed to a user for eg - MANAGEMENT , JAVA, HADOOP , PIG ,SQL, PERFORMANCE TUNING, C ,BUSINESS CONSULTING , SALES etc etc.....
NOW my query is that i need to build a machine learning algorithm to detect if there are some spelling mistakes in the so called skills. for eg if instead of sales the column has sals or like hadoop is misspelt as hadup. so i want to standardise these things.
How can i go about doing this?? I dont know Machine Learning, but i am willing to learn and code it . I am comfortable in working in PYTHON.
Any Suggestions how can i go about doing this?? Would really be great if you guys can pitch in Ideas !!
There are typically two parts to such a problem: figuring out which items are likely in error, and then fixing those.
If you assume that the majority of items are spelled correctly, then finding the likely errors is pretty easy. Fixing the errors is a lot harder to automate, and it's probably impossible to do it 100% correctly in any reasonable length of time. But you might find that if you do a good job finding the errors, fixing them manually is no big deal.
To find the errors I would suggest that you make a list of each of the skills and a count of how many times each skill is referenced in the entire data set. When you're done you'll have a list like:
MANAGEMENT, 22
JAVA, 298
HADOOP, 12
HADUP, 1
SALES, 200
SALS, 1
etc. Each skill is listed along with the number of users who possess that skill.
Now, sort those by frequency and choose a threshold. Say you choose to examine more closely anything that has a frequency of 3 or less. The idea is that items that are used a very small number of times in relation to other items are probably misspellings.
Once you've identified the terms you want to examine more closely, you can determine if you'd like to automate the change or if you will do it manually. When I had to do this, I got my list of likely misspellings and manually created a file that had the misspelling and the correction. For example:
SALS,SALES
HADUP,HADOOP
PREFORMANCE,PERFORMANCE
There were a couple hundred, but manually creating the file was a whole lot faster than writing a program to figure out what the correct spelling should be.
Then I loaded that file and went through my user records, making the replacements as required.
The big time saver is finding the likely candidates for replacement. After that, fixing them is almost an afterthought.
That is, unless you really want to spend months on a research project. Then you can knock yourself out playing with edit distance algorithms, phonetic algorithms, and other stuff that might figure out that "edicit" and "etiquette" are supposed to be the same word.
Something that works very nicely for this in the machine learning paradigm is String Matching kernels. Since these are actual kernel functions, if you want to formulate learning as an SVM they are very convenient.
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 7 years ago.
Improve this question
I have always been fascinated by computer viruses. For years I have tired to learn about them, but due to their nature people are unwilling to give many details.
For what it is worth I'm not a hacker and am not trying to build a virus.
If anyone is willing to answer this question I want to know what makes a virus a virus and how they are different from spyware.
How can they install themselves onto a computer without you noticing?
And how do worms work? How can a program replicate and move on its own? Does it contain its source code within it? And does it interface with other programs or just assess the hardware directly to spread ?
EDIT: What language would they be written in? Would you use assembly/C++ types of languages or create them as scripts in lua?
Well, a worm is simply a self-replicating piece of software. Imagine a program that copies its executeable over some link to another computer and launches it there. That's not that much magic.
A virus is simply a worm which infects other executeables, i.e. it does not replicate its own image, but it "backpacks" it to a different application's image and uses that application's execution flow to get initiated.
The user does not notice anything if there are no side-effects, and no UI interaction.
If the user is a technically more competent than the average end-user, this is very hard to achieve. Some malwares host the target system in a virtual machine so you as the user have a hard time to see anything suspicious as long as you don't figure you look at a virtual machine. Like Neo, awaking from the Matrix.
As there is no limit to what you can implement in what language, there is no language of choice. Naturally, a low-level and natively-compiled language is more versatile to do what a virus/worm must do to stay low-profile. However, there are worms and viruses written in assembly language, Basic, C, Delphi, JavaScript, whatever -- there is nothing you can not imagine here.
Spyware has similar requirements, but different goals. While a virus, and a worm, usually spreads around, either for no reason or to drop some kind of payload at some point, spyware wants to either "phone home" or open the target system so it can be attacked, i.e. inspected, easier, usually in order to get hold of a victim's data that is secret, personal, or otherwise interesting.
Hope this quick answer helps a bit. You can google more details easily at bing :)
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
My question is really very important .
When i program i have seen that i had lots of errors in programming logic + structure + a flexible when it goes for testing , i have read many books on OOPS and my all the concept are clear but i do not know where to start design of my code or project . can any body help me how to improve this part of programming skill.
although i work on php+javascript but this question is for all the programmers on stackoverflow
note- usually when i hold paper and pen i think where to start from ..
if i make something problem is how to simplyfy.... and many others which u all are facing / faced
Well, I think everyone is different as is every project. But here is what I personally do...
For my own projects, i.e. no client requirements, I start at one end or the other, either with the database structure or the UI. I then work down through the layers making sure that I maintain clear separation of concerns to make testing (unit and system) as well as maintenance as easy as possible.
One thing to note is that regardless of your approach I think the process is iterative. I will often work, refactor, work, refactor etc so don't get too bogged down with the details and feel you have to stick to them. The requirements are the key thing (whether for yourself or for a client), the technical implementation is largely irrespective.
When dealing with clients the process is somewhat different. You will need to do a fair amount of design up front so again think from one layer to the next trying to keep as much of the logic in the correct layers as possible. As an example you have your DB, then you want a data access layer (DAL) to abstract your code from the DB access. Then you want specific business logic libraries which use the DAL, this abstracts the higher portions of code from the data (they go through the business layer) etc etc.
Just think of each level and try and keep it as generic as possible, that way when you wish to change the storage for the data, you simply change the DAL and everything else works as before...
As far as starting a design of your project is concerned, whole lot depends on what you are developing, that is requirement of the application. So first thing is that you must collect information about the purpose of your application. And when we start to program, a plain trend must be kept in mind, which is, as a universal fact of programming, Input-Process-Output. So, design starts with input. Just collect as much information as you can about what will be required as your input of application. If the input is not made by your user, than it is not required to be mentioned in your front-end design (In Windows language, the so called "Form"). What user will give, is matter of concern in designing the input area (very first step to start project).
During the designing phase, constant interaction is required with user to make effective & flexible start design, as ultimately he/she is going to use. If I'm starting a project's designing, I always consider the user a lazy person, if we keep that thing in mind, our application will be simpler & easy to use. Once, you'll kick-off the start, its just a flow, that'll suggest you next step.
Hope this helps............. :-)
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
So, I'm almost 100% self taught in programming (save for a course in C after I had already taught myself C). This means that to keep myself programming, I have to be constantly finding materials (i.e. tutorials) on the web (I'm poor). Unfortunately, I've found myself stuck in a sort of limbo, where I understand the basics of programming (in theory, I'm able to grab a new language and get comfortable enough to solve a few Project Euler problems, as is evident by my time spent here) but I'm not able to get any deeper than that, like GUI programming or web interfacing.
I don't know if it's just me, but there seems to be a sort of great divide in terms of the level of difficulty in the tutorials on the internet. All I can find fall under either Maddeningly Easy or Maddeningly Difficult. Are there no intermediate tutorials out there? The kind that say, okay, you've seen this before, here's some code but we'll explain what's happening. But I digress.
Given my lack of ability to breach the practicality gap in terms of programming, I find myself stagnating. I can only teach myself the first six Project Euler problems in so many languages. I need to find something, some sort of project, before my spark dies out. I'm worried about it. I know this is such a broad question, but... can anyone help me out? Point me in some sort of direction?
You need to start making things. You can start out small, but find a project that you can contribute to or that you want to work on yourself.
If you can't think of anything "useful" to make, then start writing simple games: a tetris clone, a top-down shooter, something like that. It doesn't have to have AAA graphics but even a simple game like tetris will teach a lot about the more complex structure of a program, user interface, and that sort of thing. But at the same time there's nothing so complicated than you'll get completely stuck.
Passion is not something that will die out that easily. There are tons of local user groups/developer groups that you can join to learn from them (most of them are free) To get to some of what you defined as intermediate problem, getting a job is definitely the best solution. You could work on Dave Thomas's coding kata. For difficult ones, you can do some facebook puzzles (they get real hard at the second level and up, easily take hours to days to solve)
A couple of suggestions which I might offer, as they have worked for me in the past, when in the same situation:
1) Get involved in an Open Source Project.
One of the best ways to learn programming is to read/review/refactor code created by other programmers. You learn new tricks, as well as good style guides for formatting your code in later work, and start building a good understanding of a pile of packages which you can roll together to create solutions down the track.
2) (If you aren't already) Get a Job as a Programmer.
The single greatest kind of learning experience I have had when it comes to programming is when I need to extend my skillset to solve a particular problem. Being put in a role where you are given a problem, which, when you start, is beyond your skills and then creating a solution using experimentation, sourcing existing solutions online, referring to documentation, asking a learned colleague, etc. is great. It is almost like a trade apprenticeship - you learn as you go and sooner or later you can handle 95% of the solutions autonomously.
One thing I have seen said time and time again on various blogs and forums is that trying to be highly skilled in a wide range of languages is an almost impossible challenge - it is better to pick one (or maybe two) and then practice, practice, practice to develop it's associated skillset to a great degree.
Perhaps you should start working on REAL WORLD projects for either friends or family.
This will give you positive feedback for your efforts and a sense of "acheivement" when the job is finished.
Great programming theory is all very good, but without introducing some kind of "reward cycle" I can understand how frustrated you could become.
You need to start and finish a project that's a large enough to force you to learn different things, but small enough to actually finish. Here are some ideas:
Jabber client
RSS reader
Twitter client
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
Recently, we've come across an issue at work where if one person is working on some code by themselves, it seems to come out with the other team members looking at it and going "Huh? That's ugly, unmanageable, I need to rewrite that"
In fact, recently, I myself have had to re-factor something that was written the week before so that I'd be able to add in my (related) feature.
I know that Pair programming is the way to go for this, but we have an uneven team (3 members). As our team is being pushed pretty hard at the moment, we really don't have time for Peer Reviews (though we can do Pair Programming, as we're allowed to estimate that into our task estimates)
I'm just curious as to how people would suggest we overcome these issues with poor code being generated.
When you work alone, and produce code which your colleagues find ugly and unmanageable and needs to be rewritten, then do you:
(a) agree with them when you look at it a second time,
(b) disagree?
If (a), then the problem is that on your own, you aren't fully clarifying your code when you write it. Since pair programming is the only thing making you write decent code, I suppose I'd recommend that the "odd one out" should work on tasks which do not involve writing long tracts of bad code: bug-hunting; maybe writing test code, since that tends to be a bit less fiendish. Meanwhile, work on improving your skills at writing better code - perhaps do reviews of your own code from a few months ago, and make notes as to what was wrong with it.
If (b), then the problem you have is incompatible ways of expressing your ideas. The code may not be bad by your standards, but it's mutually incomprehensible, which in a corporate setting means it's bad code. Pair programming means what you write is a compromise that 2 out of 3 of you understand, but that's not really a solution. You need to come to some mutual agreements about what you find most difficult about each other's code, and stop doing that. And you all urgently need to start thinking of "code quality" in terms of "my 2 colleagues will like this code", not "I like this code".
Either way, you all need to work on writing code for the purpose of being read, rather than for the purpose of getting the immediate job done as quickly as you possibly can. Personally I have done this by trying to express things in the way that I think other people might express and understand them, rather than just what makes sense to me at the time. Eventually it becomes habitual. When I write code, I write it for a public audience just like I'm writing this post for a public audience. OK, so on my personal projects it's an audience of people who think just like me, whereas at work it's an audience that thinks like my colleagues. But the principle is to write code as if someone's reading it. You're explaining yourself to them, not the compiler.
Not that my code is the best in the world, but I do think I benefited in that my first job was in a company with 30-odd programmers, so I got to see a wide range of ways of thinking about things. Also a few examples of "what not to do", where one programmer had done something that nobody else could easily understand, and therefore could definitively be said to be bad. With only 3 people, it's not clear whether a 2 v. 1 difference of opinion means that the 1 is a freak or a reasonable minority. When I did something and 4 or 5 people could glance at it and immediately say "eeew, don't do that", then I started to really believe it was just a dumb idea in the first place.
I'd also recommend that if you aren't allowed to budget for code review, lie and cheat. If you're heavily re-writing someone else's code, you're effectively taking the time to review it anyway, you just aren't providing the feedback which is the worthwhile part of code review. So sneak the review in under the radar - write a function or three, then ask a colleague to look at it and give you instant feedback on whether it makes sense to them. It helps to have a conversation as soon as you've done it, with the code on the monitor, but do try not to interrupt people when they have "flow", or to get into lengthy arguments. It's not pair programming, and it's not formal code review, but it might help you figure out what it is you're doing on your own that's so bad.
I'm surprised that you don't have time to do peer reviews but you have time to do paired programming. Is the latter not a much bigger sink of time?
We also have three developers only at our company and, surprise, surprise, we're being pushed hard at the moment. I'm pretty sure my boss would laugh at me if I suggested paired programming because that would be viewed as doubling the number of man hours for a task even though in practice that's not the result it should produce. Our peer reviews are never more than an hour and that is an extreme case. On average I would say they are probably about 10 minutes and, per developer, only happen once or twice in a day.
IMO you should give peer reviews a try. You often find that the offending people (i.e. the people writing the lower quality code) eventually realise that they need to make more of an effort and the quality improves over time.
If you have three developers and each of you think the others code is not good, you urgently need peer reviews.
So:
you are being pushed pretty hard
your code is of poor quality
Do you think the two could possibly be related? The answer is to fix the schedule.
Pair up all three at once.
Set up some coding standards.
Use a dunce cap for build breaking developers.
Perform daily stand up meetings to communicate progress.
Also try peer reviews twice a week, like Tuesday and Friday.
Pair Programming doesn't have to be all day every day to be effective. I have seen good results from even an hour or two working together each week. One way to go would be to pair A & B for a while, then A & C, then A & B... with a lot of individual time in between.
It also depends a lot on the personalities and chemistry of the team members. Two of the three might work exceptionally well together and you'd want to benefit from that.
You should still pair. Set up sessions say 1 day per week and rotate the pairs. This should keep your manager happy and increase the quality of the code, improve communication. If you keep metrics on how many faults happen in paired vs solitary coding you should start to see the benfit and display this to your manager,
eg This took x man hours but saved on average y in defect fixing. Additionally the clode is cleaner and will take less time to alter then next time we touch it.
From there you will have hard statistics and you can start to code more.
Basically your story seems to be the same as mine.
No time to do things.
Mistakes happen.
Rush to fix it (taking more time)
Go to 1
You need to stop the rot.
Code reviews
Enable Stylecop that will force you to write readable, standardised and manageable code
We use code reviews. Additionally there are some single task: changing a diagram, installing some stuff...