We've pretty much licked the whole distributed thing for version control at this point. I'm not saying everything's perfect, but, from hereon out, it's mostly just a matter of continuing what has already been started.
Distributed bug tracking, though, is in its infancy stage, IMHO. It's rather inconvenient, not being able to work with an issue tracker on the road, especially since I have a tendency to forget what my changes over the past two hours were for. Yes, I know, I could just keep a log on the road and update a traditional tracker as soon as I get on the net again, but still... Keeping my options open and all that. :P
Currently, I only know of Bugs Everywhere and Ditz-- those, and the one that comes with Fossil. Of these, I think Fossil is the farthest along, which is not suprising, considering how tightly it's integrated with the version control side of the equation. I've had to jump through quite a few hoops to get my co-devs to even look at something other than SVN, but, if Fossil really is all that, I wouldn't mind doing it again.
Before I do, however, I want to ask older and wiser heads than mine: Do you have experience with these three? What do you think of them? Do you know of others? Please link to them, and let me know how they fared.
Fossil works as an 'easy to setup' Distributed Bug tracker , and has a nice autosync facility that lets developers share their bugs without intervention.
to get started,
Download the fossil binary of your choice
fossil new bugs.fossil
fossil ui bugs.fossil (runs the server)
your developers do the same
Download the fossil binary of your choice
fossil clone
fossil ui bugs.fossil
set up a cron job to 'fossil sync ...' so the bugs propagate to all users as the fossil self-hosting repositories demonstrate
There is not much more to it than that.
Edit - take a look at Customizing The Ticket System too.
Because I wanted (well, needed, really) a solution that could probably (maybe, hopefully) work right now, we went with the following setup:
Bazaar-NG as the VCS
Bugs Everywhere as the bug tracker
Zim as wiki
It may not be the perfect setup, nor even a particularly acceptable one to some, but it meets the criteria of working right now. I still would like to learn more from others; maybe I'm missing a not-so obvious trait of other solutions that would cause me to become fanatic enough that I'd bug my co-devs to switch.
Anyway, if anyone uses this, or a similar, set of tools, please let me know how it's worked out so far for you, what your circumstances are, etc. Right now, this solution of ours is all of three days old, so I really don't have much data to share as of yet.
Eric Sink has some sensible thoughts on the subject here - he's clearly given it more thought than me but he does make one key point which is that you have a different paradigm when dealing with features and bugs to when dealing with development, particularly with respect to bugs.
Additional information for people like me who're interested in the subject, but can't pull up enough relevant info through Google (either they're not there, or my Google-fu is severely lacking):
Just branched Bugs Everywhere again. bzr log --limit 1 shows the last commit to be from early October 09. The development is slow, but it's there. I haven't yet dived in to see just what exactly be offers. Documentation is severely lacking. There isn't even a quick-start guide on the site.
Ditz, using a clone of its mainline git repo just utterly fails for me. Google indicates the 1.9 releases of Ruby breaks it. Supposedly, there are git clones that fix it, but I'd really rather not mess with git.
Fossil has at least one relevant question here on SO: What do people think of the fossil DVCS? (it even has an answer from the author!). Much respect for D. Richard Hipp (author of SQLite and Fossil, as well other insanely cool things I can only use and read about on Wikipedia), but I'd like feedback from other mortals, as well.
Still not enough for me, though. There has to be at least a couple of people who've used either be or ditz for a non-trivial project-- at least, enough to be able to give an informed opinion.
I don't care about the technical side-- either the project documents it on its Web site, or I could just look at the source. What I'm looking for is real-world experience: What were the hurdles to its adoption? What is a particular project lacking? What would you add, that you really need, given maybe two years of paid time to work on it? Stuff like that.
Related
As I know there are some applications that decompile DLLs to get source codes from application files.
Not only I don't want others to have the sources but also I don't want others to use them, I mean the DLL files. so how should i lock the DLLs and how safe they are ?
Before I get into anything else, I will state that it is impossible to protect your application entirely.
That being said, you can still make things more difficult. There are many obfuscators out there that will help you make it more difficult for someone to decompile your application and understand it.
http://en.wikipedia.org/wiki/List_of_obfuscators_for_.NET
.NET obfuscation tools/strategy
That's truly the best you can hope for.
Personally, I really wouldn't bother going too deep, if at all. You'll find that you are either spending too much money or time (or both) trying to protect your application from no-gooders. These are the same people who, no matter what barriers you throw up at them, will continue to try and given the nature of managed languages, they will most likely succeed. In fact, most obfuscators can be deobfuscated with simple tools... In the meantime, you've let other important features and bug fixes slip by because you spent more time and effort on security measures.
Obfuscation is one way to protect your code. Again, the solution is relative as per your needs. If you have a super secretive program, then you would want to explore more expensive and in-dept strategies.
However, if you are developing a business application or such thing which would not be worth a lot of any hacker's time to reverse engineer, minimal to normal obfuscation strategies are good enough. As the main answer suggests, look at those links.
Recently, I came upon ConfuseEx, a free open-source obfuscator that does the job for WPF apps and more. It seems to be very powerful, effective and customizable.
ConfuseEx on Github
For DLLs there is almost nothing we can do , confusing the files is the best way , but public member will remain in the way they were before , but if you pack them in your exe file , and confuse them , no one can use them easily .
I used ConfuserEX and it was very easy to use and effective .
I want to build a free app to become familiar with what is required, but I was always confused about the steps one needs to take to START a software project.
What are the steps required in order to develop a mobile app?
I will list some of the things I think should be done but I don't necessarily know how to do. Any advice, details and technologies you have to accomplish these steps would be awesome.
Decide which platform you want to develop. What are some of the pros and cons in this area for android vs iOS vs Windows8?
How to test the app - can you get free hardware to test with a well detailed app plan? Emulator?
Detail what you want the app to do and which functionalities you want.
Research if this app already exists. What are some areas of concerns in terms of not breaking the law such as patent infringement etc?
Setup a source repository such as git (google a guide I guess?)
Look at guides to familiarize yourself with APIs and write sample code to learn what you need?
Start the development and keep doing the above as needed.
Starting a software project can be as easy as start writing code. Most programmers will have an intuition as to what needs to be done and how it could be done. The other extreme of starting a software project is to start with talking to a client (or looking at the world) and figuring out what the problem is. I find that a thorough understanding of the problem you are trying to address with a project is already a long way into getting the project done painlessly. It'll give you a good understanding of what is required for you to call your project done.
So I guess point number one becomes: know what the problem is you're solving. Knowing this will also tell you if any existing app solves the same problem to a satisfying standard.
NOTE: I am not that familiar with the Windows 8 platform so my answer mostly talks about iOS and Android. The issues raised however are broad enough to cover large parts of the Windows platform.
Platform
Selecting a deployment platform is an important part of a launching a product, and a lot of other decisions depend on the platform. We are in the unfortunate state that two major mobile OSes exist that are separate in terms of code development and reuse. When considering selecting your deployment platform you'll want to think about the audience, and the (potential) sub set of the audience that is willing to pay for your application. Android might have to most devices out there but iPhone makes the most money (also for developers). However, remember that there are lots of apps out there and most developers don't ever make any (or not enough) money out of their apps.
Getting into app development with the aim of getting rich is going to leave you dissappointed. That's not very likely, then again someone always wins the lottery as well. It is a good way though to get employed and make some money that way.
Then there is the question of programming language (Java, Objective-C or C#). This is largely decided on what you are already familiar with, and if you aren't then refer back to the previous point.
Testing
Testing the product is a tricky thing. You'll have to start off with the emulator (which is usually provided with the development pack). Sooner or later however you'll have to test the app on hardware. I doubt you'll get your hands on free hardware but borrowing from friends and relatives is always an option. There may also be businesses that rent out test hardware to developers, if there isn't then I suppose that's one business idea to work on.
The platform choice will affect this also. Android is running on a much wider range of hardware than iOS.
Patent infringment
I don't know that much about patent issues, other than software patents are nasty. As a single developer I wouldn't be too worried about infringing on patents, the main purpose of them is to keep competitors at bay. What usually ends up happening is that big companies kill off competition with patent lawsuits, or they buy a smaller company that holds a nice collection of patents.
If you want to be on the safe side (meaning you own a company and are really doing this to make money) then talk to patent lawyers.
Code repository
A code hosting service like GitHub is fantastic in that it not only provides a place to have you code, but it also provides issue trackers for keeping notes on the functionality that is still missing or bugs that have crept up in your software.
The best places to start learning about Git are git-scm.com and the GitHub help pages.
Software development plan
Your last point explodes to a thing called software engineering. There has been lots of research into different ways of managing software development projects. The idea being that software development tends to be extended over long periods of time, the requirements of the project change during the project (as you learn more) and the project can involve anything from 1 to 100s of developers. Some way coordinating work between those developers (and all other parties involved like customers) has to be formalised, enter software engineering. The aim is to define a methodology and project structure that guides the development process and makes it more likely that the requirements are met at the end of the project.
Some models worth looking into include (Test Driven Development and other agile methods).
Finally I would add to the list of things that need to be done
Research libraries, note that this comes before familiarising yourself with the APIs of those libraries.
What software already exists that does a part of what you want to achieve. This goes partly back to the question of what platform to use. Apple has put a lot of attention in developing easy to use frameworks to support iOS app development. I am not that familiar with Andoird's or Windows 8 but the less code you have to write the faster the product will be done.
1 http://mobiledevices.about.com/od/kindattentiondevelopers/tp/Android-Os-Vs-Apple-Ios-Which-Is-Better-For-Developers.htm
There is only one step needed: Just start that project!
You are going to develop a free application, so it should be fun to do that. Choose whatever you like and keep going:
Make sure you are productive enough -- 10 Laws of Productivity
Avoid complexity -- Occam's razor, KISS principle
Let CI system do the boring stuff -- Machines should work; people should think.
Read books and improve yourself.
Please also avoid blind decisions. If you simply try several available options you'll eventually find the best way to achieve your goals. Do some PoC and decide. Nowadays 1-2 hours should be enough to start with any technology. This is the rule of maturity. You have your own goals, so it is better to avoid immature solutions.
Happy coding.
CPlayer I came to this forum with the same question since I am new to mobile app design and want to make my own app. I realize it is important to take certain steps in the correct order so that wasted time is minimized or eliminated. I did some research and came across two online sources I believe, if they are put together as one, will make one better source. The links are:
http://answers.oreilly.com/topic/2311-a-mobile-app-development-checklist/
http://mobiledevices.about.com/od/kindattentiondevelopers/ht/How-To-Create-An-App-For-The-Iphone.htm
Good Luck,
laroice
I've been working on a drupal site. During the course of editing it i've added data, removed fields, made new fields, removed data, and added more data. Now the site is almost ready to go- but I feel like the database is very messy (with revisions to fields, etc)
How can I best clean-up my site before the official roll out? Also, what are good practices to use while adding/deleting fields so I dont run into this?
This is a workflow related problem. user491844 mentioned the usage of Features and #luksak told it's not a real answer, but I would like to explain why the usage of Features would be actually one kind of a solution to this.
Normally we do multi-stage development, meaning that you should have a separate environment for development and for production (at least; often a third area called staging is used for acceptance tests etc.: development → staging → production). This means you should try new things on the development environment and whenever satisfied with the result, move it one level upwards. This can be done in multiple ways, one possible answer is Features. In general, you should take a look on how code-drive development can be done.
It's very easy to see why this approach would actually solve your problem: in production, you wouldn't have to clean up things often, because it wouldn't have any extra cruft that a sandbox often has. It also adds a layer of protection: if you break the sandbox, you can just clone the production site and you're good to go. Using Features with added version control (probably Git) also provide a fine way to keep things in a safe place, allows documenting what's happening and makes re-using the different segments of your site possible - which is going to be a very good thing later if you're building multiple sites.
If you have a complete site, it's possible to "Featurize" it, but you will have to be very careful on how you build up the features. In general, try to build small features which only contain components related to a given functionality. You will end up with a lot of small features this way, but it makes handling dependencies easier. You can find a lot of articles on how to split up your features properly: like this and this. Good organization is essential.
One thing I would also mention: in production, you will probably want to keep the site as lean as possible, so setting up caching, disabling development stuff and UI components of some modules etc. might be useful. You can find several useful modules which can help you in production, one of those is Production check.
There are a lot of articles on this "how to move to production" topic that you should research to see the recommended steps, see this for an example.
So, I work in a fairly small IT section. We have a trouble ticketing system that about half of our end users use. Some of my coworkers don't really do much to encourage our end users to use the system we have in place. The end result? Constant interruptions because end users will get us by IM or come to our offices directly for trivial things. This can obviously make it difficult to do a good job of writing code.
Now, I suppose I could just say "hey, would you mind filling out a trouble ticket next time?", but then I'd come off as the bad guy because others won't do that. I also don't want end users to feel that I'm unapproachable. I just want them to understand that there's a proper way to ask for help.
So what's the best thing for me to do in a situation like this?
Make it appealing to do so.
Mention to the user that issues with trouble tickets are viewed by the entire development team and have been found to get fixed significantly faster. Say that anything without a ticket has the potential to get lost in the shuffle. Provide them outward facing links so they can view the progress and developer/support comments on their ticket. Provide email alerts so they feel like they are part of the process and have instant information about their issue.
Make it as frictionless as possible.
Make the user entry part of the system as easy to use and as intuitive as possible. No one likes filling out tickets and I'm certainly not going to jump through any hoops to do so. No logins, no sign-ins, just type out my issue and contact information and go.
Talk with your team.
Ultimately, no amount of hard work on the above systems is going to matter unless your team and you are on the same page. Call for a team meeting and talk with them about the issue. With your boss present, try and put it in terms he can understand. Mention valuable time lost, issues tracking customer problems which aren't in the system, etc, etc.
Sounds like your manager is letting you down by not forcing users to submit a ticket before getting help. The problem starts there and only continues to your co-workers allowing such behavior. We use redmine at work for application support and have made good progress in telling users "submit a ticket and we will look in to it" but it has to be a consistent voice from all people involved.
Use a little psychology on them. For people that don't send in trouble tickets, remind them that 80% of the people in their department use the ticketing system. Even if it is a lie, it will encourage good behavior because of the bandwagon effect. Remember that the more similar the person is to demographic statistic, the more likely it is to influence their behavior. So "your immediate coworkers" will work better than "people in this entire company."
The people that use the ticketing system should get a gold star, no, seriously.
There was a very brief article in February's Harvard Business Review on using social pressure to influence behavior. It discussed some new research but the article didn't include references.
You don't. Users hate that stuff even I do. Instead your policy should be "don't make me think". You have to collect all you need yourself and automatically handle this in an invisible way to your users. After they opt in at install.
You probably won't make much headway unless you convince your coworkers to use the system first. After you've all agreed on the process you want, then you can talk to your users. If everyone on your team is playing by the same rules, you can probably force your users to use the system by having slow turn-around times for issues not entered into the system, or maybe even forget them altogether.
However, even IF you can convince both your coworkers and your users to enter tickets, you'll probably still find the tickets are incomplete/not informative. We've all seen plenty of tickets like "Feature X is broken, fix it plz" and offer no other information. Depending on the number of tickets you get per day, I would probably just bite the bullet and walk over the user and see what their problem is first hand.
We often log a ticket on the user's behalf in this sort of case.
At my old workplace, I was told that nothing could be done without a trouble ticket. When I asked why, I was told that the support team's productivity was measured by using trouble tickets. This had the effect of forcing me to use trouble tickets (since they were required), and giving me the motivation to do so (I didn't want my coworkers to look bad).
At my new workplace, all technical support is subcontracted out. I literally have to call tech support, and they create a ticket on my behalf.
Also - stop encouraging the behavior. Use your IM filtering options to only appear online to the dev team. Don't check your email - or setup filters that filter the high priority stuff (your boss, your dev team) to your inbox, and everything else to a folder you check once a day or once every other day.
Simucal's advice is good. You -will- have to tell them to "file a ticket" instead, at some point. If you ask them after the fact, they aren't going to care because they got what they needed.
A great way to handle this is to have a dedicated person for support. My team did this, and it helped our productivity immensely and eliminated at least 90% of our interruptions.
Barring that (or lieu of), you can each rotate daily as to who gets to handle user requests. This has the upshot of making a trouble ticket more-or-less required; its needed to keep track of what happened in the request when someone else starts working on it. Over time, this also brings more cohesion to your processes: people create small scripts to do common tasks, work that is done is moved into revision control, etc.
I've been asked to write code/design things in an interview. Sometimes even to provide code samples. Very reasonable and very wise (always surprised when this DOESN'T happen)
I had a job a year or so back where the code was so awful that I would not have taken the job, if I'd seen the mess I had to deal with ahead of time. And I can't tell you how many horrendous databases I've had to work with.
Is it out of the question for me to ask them to provide a code sample and to view their database design? Assuming I'd be happy to sign an NDA, part of me feels it would insane to take a job without examining the codebase or database I'd be working with.
Anyone done this?
Update
This would be something I would ask later in the interview process, if things were proceeding well and I felt an offer was forthcoming.
It's also in the context of working in a small shop or small project as my preference is to avoid places that use phrases like "get a developer off the floor"
You can definitely ask. The answer may be "No," but nobody should consider that to be a bad or inappropriate question.
If they won't show you the code, you should definitely take that into account when you decide whether you want to accept an offer. I would take it as a sign that at least one of the following things is true:
The code is so horrible that they know you'll run away screaming.
The company has an ultra-secretive trust-nobody culture (which I would hate).
The company thinks they have such amazing code that just glancing at it would turn you into a superstar competitor. (In other words, they're self-deluded morons.)
They have glaring security holes that they hope to keep secret.
The people who are interviewing you don't know how to get the code themselves. (In which case you are not talking to the right people.)
I'd be more interested in seeing the company's systems - i.e. test framework, release process, autobuilds.... The presence or absence of those would tell me a lot more than a couple hundred lines of code.
I did ask: "Can I see some code and talk to programmers working here?"
The employer replied: "Sure! Come you can directly talk to our lead programmer of our information system!"
What an honor!
they showed me concept papers
I could talk to the lead programmer
they showed me a small part of a very new project telling: "this is just a prototype, direct3d is so sketchy, that's why this code is so messy"
It turned out that:
the lead programmer left the day I arrived
the software he had the lead, was a big mess
somehow I ended up spending 50% of my time, fighting against the mess
None of the candidates we have interviewed have ever asked that; however, many of them have been co-ops/interns in the company so they are familiar with our code...
Having said that, it is highly unlikely we will show our code to ANY candidate, regardless of an NDA. I would be happy to answer questions about what technologies we use, what system we use for revisions, practices around, etc. Actual code though? No.
Also in a large enough system (as ours is) someone can just show you the "best" code there is...and you would be where you started :) As for a database design...both companies I have worked at have had enormously large databases (university, corporate company)...so that wouldn't work either.
I've asked this in interviews with Xerox PARC, a startup, and Yahoo.
At PARC they sat me at a workstation with the code I'd take over if hired, went over the structure of the codebase super-briefly, and left me alone for around 20 minutes. This was enough to get an idea whether I could stand working with it, though I'd have liked some more time, like an hour total. Afterward I asked about a design decision that seemed dubious, and we chatted about the design and the style in general. This didn't just tell me more about the job, it told them more about me: did I explore their code top-down or bottom-up, what did I pick up on or ask about, etc. Valuable all around.
At the startup, they set up a separate meeting on another day, bringing in the author of the code (who wasn't an employee); we sat down at a laptop and went over things together. It was an unusual request to them and I think I had to sign a new NDA. This was once again worthwhile: my earlier interviews hadn't really cleared up what this fancy AI language was all about or what they'd want me to do with it, and sitting down with some concrete code blew away a lot of fog.
At Yahoo, I didn't see much of anything; I don't recall just what their response was. If I'd seen the code I ended up dealing with I might have had second thoughts (though it worked out all right in the end). (Both of the above codebases that I did get to see seemed generally nicer; the PARC one was open-sourced later on.)
In all these cases I shared some code of my own with them.
If you are going to do this then I think you need to give them a little warning so they can prepare an NDA and get an apppriate environment set up in which you can see it. Also be prepared to dedicate a little time to understanding why the code is in the shape it is.
If you turn up at your first interview and say, right, can I see the code, all but a very few people will say no. And not necessarily because they are evil and don't want to show you, but because it just isn't as simple as saying yes.
In my experience as a recruiter for a large software company it would have taken a considerable amount of time for us to disclose enough detail of the code and internally developed frameworks for any candidate - however bright - to be able to make a meaningful judgement of its pros and cons. We would only contemplate doing that if we were serious about hiring them.
If I were asked that question I woul say yes, come back another time and we'll arrange something. I would get a trustworthy developer off the floor and have them bring a laptop to the next interview and show a little of the code.
The reality is pretty much any software project which is of a reasonable size and has been in existence for more than one release will have some horrible scary rubbish in it.
Similarly to some of the other responses, I've never had a candidate ask to see our code. Even if they did I've be very careful to do so and most likely would not. As Swati mentions, pretty much any non-trivial system will have sections that look good so even seeing the code won't help that much.
Better than looking at actual code is the Joel Test. Basically it is 12 yes or no questions that you can ask an employer. The more yes answers, the better the work environment is expected to be. It's obviously not a hard and fast "rule", but it would seem to indicate those companies that take code (and coders) seriously.
I can't think a reason for not showing some classes or talking about the architecture they're using. From my point of view it's like asking them to show you where are you going to work (room, table, chairs, teammates...).
Anyhow, asking for it will show them you're interested in best practices and also that you're not desperate about finding a job at any price, and don't know how this can hurt.
Go to open source projects. There you don't have to ask for permission to see the code.
It can't hurt to ask and this is a very good idea which I am going to add to my checklist of questions to ask employers.
An interesting idea, but I don't know how many companies would go for it. I know we can't do it where I work now.
I think the biggest problem you're going to have with this is that I have found that a lot of people take offense to people not liking their code. It's like criticising someone's therapist, it's just not a good idea to be an outsider and do it. Seeing the code and then not taking the job could give you the reputation that you're arrogant or not good enough to work on the code and that's why you didn't take the job. It might save you from getting job you don't want, but it could give you a negative reputation down the line. I live in a sizable city, but the IT people still know one another and word spreads. People in our field have egos, and it's easier to trash somoene else's reputation than it is to admit that code you wrote isn't up to par.
Even if they showed you some code, would that be sufficient for you to come to a rough conclusion about the quality of code that you would be spending time with? For example, at my previous place, one of their products was a large e-banking middleware application. The core of the application was in C++ and designed and written in a great way. However, the extensions (which by far covered a large part of the application and its various different versions), which were in C++ too, that were mostly coded by the less-experienced and less-knowledgeable developers were a pile of crappy code (which I had to fix and work with or write from scratch at times) slapped together to just somehow work. If I had asked them to show me a snippet of the code during the interview, and they had shown me some of the core stuff (the extension code actually mostly contained the client-specific business logic so it wouldn't make much sense without the business-domain knowledge, etc), I would've thought that the overall quality of the code is good (which was not completely the case).
More important than to ask for code snippets, I believe, is to ask them for which source code control product they use (run away from companies that answer "Visual SourceSafe") and which methodology they use: "Agile" or "Scrum" sends positive signals, CMMI usually means company loves bureaucratic processes, if they give you a "huh?" then you're warned ;)
I think this is a great idea; however, as an employer, I would be hesitant -- even with an NDA -- to provide an interview candidate samples of real, working code unless I was pretty sure I wanted to hire the person.
The problem is they will show you a little bit of code, but each of their programmers will write code in a different way. You are unluckily to have to work on the part of the code base that is well written.
Asking to see their coding standard and how they enforce it is more likely to be of use.