I'm going to be creating a few small mobile applications and have managed to find a great online Git repo hosting services that is free. It even comes with online issue tracking software but appears to be mainly geared towards the development team. I was hoping it would also have an interface for end-users to log issues/features and allow them to vote on what they wanted but it does not have this. It does expose an RESTful API but I didn't want to go down that path and wanted something ready to go (once configured).
I don't think I need it to be integrated with the Git repo so having something that is purely standalone would be great but I would definitely want something that is online as I don't want to install software on my local PC.
In summary, my requirements are:
Free or very cheap
Simple end-user interface to allow users
to submit issues/features
Allow end-users to vote on their own or other users issues/features
Visible status of issues/features (i.e. whether they are pending, in progress, rejected, fixed etc)
A more advanced management system for me as a developer to manage the
issues
Some basic reports/charts/graphing would be great
Email/RSS notification of new issues/suggestions would be great too
Something that is ready to go after some configuration/settings.
Can anyone recommend something that would be suitable for this?
TIA
I based my question on a website I saw a while back but couldn't find it. Anyway, I've now found it again (it's called http://www.uservoice.com/). It's not really issue tracking but more of a way of letting end-users report features and allow them to vote on them. The important thing is that it is a very user friendly interface which is perfect for end-users. Obviously, I would then need to maintain issues/features in my own system (e.g. Mantis) and then manually sync features requested in uservoice to Mantis but that shouldn't be a big issue. Anyway, this perfectly meets my needs for my low volume applications at the moment.
Related
I have a business idea which I want to materialize for sometime .. I recently shared my idea with 2 close friends who also found it very interesting, new and doable plus the cost included for the project to start is reasonable and they have planned to invest in it. Much of the success of this project app depends on the proper marketing element out of which most of the time, you have to personally meet up with clients/vendor and make them use your application.
The idea is to connect local ecommerce (retail shops, businesses, vendors, etc.) with users/customers through a messaging app mostly similar to whatsapp. I have already started to look for a xmpp/jabber developer who can accomplish our requirements. We are expecting him to develop the app and also set-up the server requirements. Our budget lies within $3000-4000 range for the project to initiate.
I want the app to have the following aspects:
a) user friendly GUI
b) highly scalable (planning to start within my city located in south asia)
c) location sharing (want users to navigate nearby shops/vendor offering their type of goods/services)
d) have a user review feedback against vendors and an additional page for vendor profile/rating system
e) only customer - vendor chats with functionalities like camera snaps, audio recording (just like whatsapp).
f) both for ios and android
Now the whole idea outlaid, after reading lots of articles, discussion and tutorials, I have some questions (I am a non-technical person btw):
1- I believe ejabberd is the best option as compared to tigase or prosody due to high scability. Is this ok to go with or should I look at other xmpp servers?
2- Currently, I am planning to launch this application within my city (rated as worldwide no.2 as per population stats of above 25m people), should I set-up a local server with high internet bandwith and a powerful machine or should I outsource it to some xmpp hosted server in the US (as their technological infrastructure has always provided quality service).
3- Should I be worried about the developer stealing the source code or is there any effective way to minimize this risk?
4- Any ideas what other things I am missing. This is dead serious for me and I am willing to do anything to get this project on the road.
(P.S.: The idea for this app is similar to the existing app called Lookup but I am planning to add some variations to it)
Thanks and sorry for being a bit lengthy ..
Regards,
Ahmed
ejabberd is indeed likely your best bet. However, be careful about the budget. To launch a quality service in an highly competitive area you have to have a significant budget, both development and marketing, if you expect your project to succeed.
I've been developing a web app locally on my local MAMP computer for the last few months. Now I am ready to launch it while continuing to add enhancements/fixes. So, I am wondering what is a good way to implement a development AND production server in order to efficiently manage updates, prevent overwrites, and seamlessly add other developers into the workflow. I also want something that has a minimal learning curve for me. Personally, for whatever reason, I've never been able to fully grasp version control systems like Git or SVN so I am hoping for an easier solution until I am able to invest more info the business.
As I see it, the options that I have are:
Spend more time learning Git before launching. And hoping that I don't break anything while further developing my app.
Buy two hosting accounts. One for Dev and one for Prod, where only I can do the deployments into Prod. I suppose I'd have to keep track of all files we've modified in a spreadsheet that are deemed ready for deployment.
Editing right on the FTP (no Dev server).
Are there any other options that you can recommend? I've heard that there are some new types of Web Hosting companies that can do the heavy lifting...
While personally, I have had good experiences using svn/git for multi-developer websites, I can understand your reticence to start relying on something you are not entirely familiar with. Unfortunately, I do believe that is your best option, but failing that, you might try using subdomains. My former employer would create test area on the disk and point beta.thedomainname.com at it. When bug fixes or upgrades were complete and verified to be working in the beta directory, the entire directory would be copied over to the live domain. Not the most elegant solution, but it worked. It certainly is cheaper than buying two hosting accounts.
I want to know if there is a possibility to add a team member in iPhone Developer Portal that will have permissions (see / modify / update) ONLY to one application.
The reason - there is a big company (that has many applications in the App Store) that uploaded one of my applications and I have hard time to send an update to the application (can't access the guy that is responsible for all the iPhone applications).
I want to ask them to add me as a team member, but they might agree only if I won't be able to see/touch any other application except the one that I have developed...
Thank you.
I don't believe this is possible; there are no per-app permissions.
The available "roles" are explained here:
http://developer.apple.com/programs/roles/index.php
It seems a bit odd if they trust you to write an application that they've published under their corporate identity, but don't trust that you'll only change what you're meant to. Either way is seems the only solution to your problem is likely to be a non-technical one; you need to find a way to get to that guy, whether it's appealing to his better nature, or finding a path to someone more senior who can lean on him.
I've been tasked with setting up a version control for our web developers. The software, which was chosen for me because we already have other non-web developers using it, is Serena PVCS.
I'm having a hard time trying to decide how to set it up so I'm going to describe how development happens in our system, and hopefully it will generate some discussion on how best to do it.
We have 3 servers, Development, UAT/Staging, and Production. The web developers only have access to write and test their code on the Development server. Once they write the code, they must go through a certification process to get the code moved to UAT/Staging, then after the code is tested thoroughly there, it gets moved to Production.
It seems like making the Developers use version control for their code on Development which they are constantly changing and testing would be an annoyance. Normally only one developer works on a module at a time so there isn't much, if any, risk of over-writing other people's work.
My thought was to have them only use version control when they are ready to go to UAT/Staging. This allows them to develop and test without constantly checking in their code.
The certification group could then use the version control to help see what changes had been made to the module and to make sure they were always getting the latest revision from the developer to put up on UAT/Staging (now we rely on the developer zip'ing up their changed files and uploading them via a web request system).
This would take care of the file side of development, but leaves the whole database side out of version control. That's something else that I need to consider...
Any thoughts or ideas would be greatly appreciated. Thanks.
I would not treat source control as annoyance. See Nicks answer for the reasons.
If I were You, I would not decide this on my own, because it is not a
matter of setting up a version control software on some server but
a matter of changing and improving development procedures.
In Your case, it might be worth explaining and discussing release branches
with Your developers and with quality assurance.
This means that Your developers decide which feature to include into a release
and while the staging crew is busy on testing the "staging" branch of the source,
Your developers can already work on the next release without interfering with the staging team.
You can also think about feature branches, which means that there is a new branch for every specific new feature of the web site. Those branches are merged back, if the feature is implemented.
But again: Make sure, that Your teams agreed to the new development process. Otherwise, You waste Your time by setting up a version control system.
The process should at least include:
When to commit.
When to branch/merge.
What/When to tag.
The overall work flow.
I have used Serena, and it is indeed an annoyance. In addition to the unpleasantness of the workflow overhead Serena puts on top of the check in-check out process, it is a real pain with regard to doing anything besides the simplest of tasks.
In Serena ChangeMan, all code on local machines is managed through a central server. This is a really bad design. This means a lot of day-to-day branch maintenance work that would ordinarily be done by developers has to go through whomever has administrator privileges, making that person 1) a bottleneck and 2) embittered because they have a soul-sucking job.
The centralized management also strictly limits what developers are able to do with the code on their own machine. For example, if you want to create a second copy of the code locally on your box, just to do a quick test or whatever, you have to get the administrator to set up a second repository on your box. When you limit developers like this, you limit the productivity and creativity of your team.
Also, the tools are bad and the user interface is horrendous. And you will never be able to find developers who are already trained to use it, because its too obscure.
So, if another team says you have to use Serena, push back. That product is terrible.
Using source control isn't any annoyance, it's a tool. Having the benefits of branching and tagging is invaluable when working with new APIs and libraries.
And just a side note, a couple of months back one of the dev's machine's failed and lost all his newest source, we asked when the last time he committed code to the source control and it was 2 months. Sometimes just having it to back up stuff when you reach milestones is nice.
I usually commit to source control a couple of times a week, depending if I've hit a good stopping point and I'm about to move on to something different or bigger.
Following on from the last two good points I would also ask your other non-web developers what developmet process they are using so you won't have to create a new one. They would also have encountered many of he problems that occur in your environment, both technical using the same OS and setup and managerial.
Most of the work I do is with what could be considered enterprise Web applications. These projects have large budgets, longer timelines (from 3-12 months), and heavy customizations. Because as developers we have been touting the idea of the Web as the next desktop OS, customers are coming to expect the software running on this "new OS" to react the same as on the desktop. That includes easy to manage automatic upgrades. In other words, "An update is available. Do you want to upgrade?" Is this even a realistic expectation? Can anyone speak from experience on trying to implement this feature?
At my company we have enterprise installations ranging into the thousands of seats. If we implemented an auto-upgrade, our customers would mutiny!
Large installations have peculiar issues that don't apply to small ones. For example, with 2000 users (not all of whom are, let us say, the most sophisticated of tool users), tool-training is a big deal: training time, internal demos, internal process documents, etc.. They cannot unleash a new feature or UI change without a chance to understand how it fits in their process and therefore what their internal best practices are and how to communicate that to their users.
Also when applications fail, it's the internal IT team who are responsible. Therefore, they want time to install a new version in a test area, beat it up, and deploy on a Saturday only when they're good and ready.
I can see the value in making minor patches more easy to install, particularly when the patch is just for a bug-fix and not for anything that would require retraining, and if the admins still get final say over when it's installed. But even then, I don't believe anyone has ever asked for this! Whether because they don't want it or they are trained to not expect it, it doesn't seem worth it.
Well, it really depends on your business model but for a lot of applications the SaaS model can end up biting you. It's great for a lot of things but for some larger applications the users are not investing as significant amount up front and could possibly move to something else before you've made any money.
See
http://news.zdnet.com/2424-9595_22-218408.html
and here
http://www.25hoursaday.com/weblog/2008/07/21/SoftwareAsAServiceWhenYourBusinessModelBecomesAParadox.aspx
for more information
One of the primary reasons to implement an application as a web application is that you get automatic upgrades for free. Why would users be getting prompted for upgrades on a web app?
For Windows applications, the "update is available, do you want to upgrade?" functionality is provided by Microsoft using ClickOnce, which I have used in an enterprise environment successfully -- there are a few gotchas but for the most part it is a good way to manage automatic deployment and upgrade of Windows apps.
For mobile apps, you can also implement auto-upgrades, although it is a little trickier.
In any case, to answer your question in a broad sense, I don't know if it is expected that all enterprise apps should make upgrading easy, but it certainly is worth the money from an IT support standpoint to architect them to allow for easy upgrading.
If you're providing a hosted solution, I wouldn't bother. Let the upgrade happen silently (perhaps with a notice that you did it). If you're selling an application that's hosted on their servers, let the upgrade decision be made by a single owner, not every user of the app.