I am planning to release a .NET product as Beta in the next couple of weeks. I want to know what points should be considered before releasing a product. I think the following needs to be taken care of:
Professional Icons/Splash and About screens
Obfuscation of assemblies
Sign the assemblies - Strong Name
Professional Security Certificate (Verisign/Thwate) - Authenticode signing assemblies
Google AdWords, AdSense and Analytics
Writing blogs etc about the application features
A way to get bug/features from BETA users
Basically the question is how to release an effective BETA and make my product popular?
Obfuscation of assemblies
Only if obfuscation does not decrease the quality and usefulness of (automatic) bug and crash reports.
Professional Security Certificate (Verisign/Thwate) - Authenticode signing assemblies
I don't think this is an important point for a BETA. If you can afford it, its a plus. However, it won't make your application more popular. Also, you won't loose potential users if you miss a certificate - whoever downloads and installs your application will not abort just because your stuff is not signed.
But there's another point missing: you need a fancy website. 'fancy' means: it must look professional, fit to your product and lead straight to a download link. The product needs to be easily installable - really easy. Small download size is also a plus in my opinion.
Writing blogs etc about the application features
Increases your google ranking, but needs to be used with care. If you fill hundreds of blogs, everybody will know it's YOU advertising your product. Nobody likes self-advertising. Let your users spread the word for your. A good application in a market niche won't need much advertising ...
Professional Icons/Splash and About screens
Is a good point to make the application look more polished, but the effect on potential users needn't be positive: nobody likes BETAs with awesome splashscreens and icons if they crash all the time.
The question
how to release an effective BETA and make my product popular?
has little to do with all the points you stated.
It is 95% marketing thing than technical.
But I would consider the most important ones for Betas:
Easy way to submit bug-reports/feature request (2 clicks, no more; 1 minute of user's time).
Usability.
Product demos to get started easily.
The first is crucial as it will give you the first feedback on the application.
Related
I am an azure customer and i have had very bad experiences with the support so far. The developer support ($25/month) does not help with server outages because they take 8 hours to respond.. and since everyone is in india or some foreign country, that means all i get is an email, so i respond and wait another 8 hours for a response.. theres really know way to get an issue resolved any faster than 2 days it seems.
So my question, what are your personal opinions/experiences of the azure premiere support ($300-$1000/month) vs developer support? Is premiere support American engineers or still from india? Are the engineers more knowledgabe or are they the same as developer support but faster response time? And opinions would be helpful (i have the link to Microsoft's website, i want real info from people who have used it, not sales talk :) )
#kwill stated:
Every time you open a support incident the first communication you
receive from the support engineer will include their normal working
hours along with instructions on how to get support from another
engineer in a time zone that more closely matches yours.
From personal experience I can tell you this:
While this may very well be true, however, the first communication with the support engineer is the tricky part. The last ticket we created, after almost a week we're still waiting on that first communication with a support engineer which had expected response: 4h ; This is with a Gold support account.
I used all service plans (Developer > Premium), not only Azure but also a few Microsoft products (e.g. SharePoint). First of all, I'm not going to criticize Microsoft service supports but most of the paid tickets I raised give me NOT good experience.
Note that Developer support plan aims to help basic troubleshooting. I'm unsure if you are given an experienced engineer (or you are lucky enough) but the first level is support escalation engineer. I have no idea with this role but per my experience, people with this role have no developer background. They have skills in system, network and IT background enough to kind of understand what you encounter, and may answer general questions. In the loop of email also has a few people to monitor the case.
Standard Plan is quite similar to Developer plan. The difference is the support time (24 x 7) because Microsoft engages people from different shifting time zone. The role is still Support Escalation Engineer.
Professional Direct is quite more professional and has experience with the specific Azure service you encounter. This person may come from Premier Field Engineer (PFE) team who understands the service and also have good troubleshooting skills. You are asked as deep as possible so they can drill down to see the root cause.
Premier Support is more to consulting, architecture and code review. If you encounter system or application error when working with Azure, I don't recommend you to pick this plan. Go with Professional Direct plan is enough. Premier Support also has (but rarely) PFE guys engaged. Role engaged mostly is Consultant and Architect (not Cloud Solutions Architect).
My experience (mostly):
I was shared many long articles (from Microsoft Docs for Azure) which even had obsolete information, missing guidance or unclear points without indicating which I should pay attention to. And you know articles from here https://learn.microsoft.com/en-us/azure/ have so many issues (e.g. wrong API version, wrong configuration, invalid class,invalid directive, poor documented SDK sample....)
Developer and Standard Plan would not give much value. Slow response and no consensus (someone handles case then off business hour. Another one takes over and asks what is encountered again). Such a loop resulted waste of time.
Professional Support gives best practices of DOING, or DESIGN, without actually understanding the scenario. Every design has a reason and decision consideration. It's not just giving a documentation then recommend to follow.
Premier Support: it is good but don't really expect something so high. Sometimes your customer asks you to open Premier Support ticket to JUST get confirmation of valid architecture design or coding pattern from Microsoft.
Again, I really love Microsoft and would like to make it better by giving positive feedback.
Kris, the Azure support team is a 24x7 global team with engineers in every region of the world, including the United States. The US based team is the largest team since that is the time of day when the majority of incidents are submitted. All of the support plan options, severities and response times, and email/phone options are available at http://azure.microsoft.com/en-us/support/plans/.
Every time you open a support incident the first communication you receive from the support engineer will include their normal working hours along with instructions on how to get support from another engineer in a time zone that more closely matches yours.
If you ever feel that you are not getting extremely high quality support you can always ask to speak to that engineer's manager, at which time a manager and an escalation engineer will review the incident to make sure you are getting everything you need.
I have been planning to build a Dentist Application for the use of the Dentist to add patients(with medical profiles...), organize visits, manage balance/fees....etc
I know Java, .NET( C#) (some windows forms), and Python. Do you have any suggestions with the language I should maybe start with and the framework and IDE that will make my life easier (and help me finish in a good amount of time). This program will be connected with a database of at least 1000 patients...
IDE's I am familiar with : eclipse, Netbeans, and Visual Studio.
I want suggestions with reason explanations (why would you favor C# over Java ....compatibility....etc)
Thanks,
It's not the database side, or even the programming environment, that will be the issue for a dental practice.
I consult for a dentist friend of mine, and the opportunity arose to sell him a fully-functional contact/document management application to run his patient database.
In the end, I couldn't in good conscience recommend my own application, because not being designed for the dental sector, it lacks the specialised interfaces with dental imaging systems.
Databases, appointments, invoices, etc, are easy.
But what a dentist needs is something that integrates with the dental records themselves - the X-ray images of teeth. It needs a simple UI, easily usable by the dental nurse while she works with the dentist while he has his hands in the patient's mouth.
We could have written a suitable graphical interface to an image library (imagine a diagrammatic representation of the teeth in their relative positions in the mouth, linked to the images themselves), but it wasn't worth it - especially as there are several highly specialised dental packages around already.
I suggest to start with some research on the subject (the dentist domain) and to make a decent functional design before you start to think about IDE's and languages.
And then try to figure out some other things:
For instance, will you make a SAAS or a windows client, do all your customers have internet access. Iis the sensitive patient data allowed to be stored on the web.
I believe that question is very relative to the person programming. I think as the developer you have to figure out where you would be most successful at or what you want to get out of the project. If you are using this project to make money then do what you are comfortable with. If you are using it to better yourself as a developer then pick a language you are less confident in.
The one thing I want to add, is remember PHI (Protected Health Information). So, you have to have patient privacy in mind when building an app like this.
If it were me... I would write something in .NET and use Visual Studio which works very well for windows forms. Windows forms would work very well in an office environment.
Just my 2 cents.
First introduce yourself to the business knowledge. Healthcare programs aren't written overnight and you have to take into account that you need to have a very secure application and probably also need to keep years of information (the program I was involved in in 2001-2002 had to keep 30 years of patient history due to Belgian law).
Choosing the technology is actually entirely up to you: what are you good at? Can you find already prebuild pieces of code or controls ...
You can write such an application in any of the languages you have mentioned.
Research the features you will need and the support you can expect from each language and the different available libraries.
You need to come up with a good design first (regardless of language/platform), and make sure you have all the requirements - how many people should be supported in the system, how many concurrent users, privacy of data, security features, access patterns etc...
You should probably use the language you are most comfortable with, in particular if the features you require have similar support in the different languages/frameworks.
Is there a way of offering the flexibility of Excel/Access development that end users love while instilling centralised IT management so data and logic is secure, backed up, version controlled etc. The common options are to re-write in C#/ASP.Net/Java/Python/Your Choice, but that takes away control from the users. Is there a better way, and what do you do at your site?
There is a universal issue of users creating fantastically useful Excel/Access mini-apps that the IT department would like to bring under control. Users love the flexibility that Excel affords, especially on the fly changes, graphing and data import/export. In Access we have brilliant QBE. The downside is that after a short while there are legions of out of control spreadsheets/mdbs which are mission critical, with lots poorly understood business logic, and brittle code, they're a pain to support especially as staff move on.
This puts the IT dept in an awkward spot, they'd like to support these apps, but don't know enough about them. This is made more difficult as they are typically insecure with zero documentation.
Having been of both sides of the fence I would go after the root cause of the problem. Why do uses make their own little apps? Because it is too hard/expensive/time consuming/never turns out right when they go through the “proper” channels.
The other thing is they tend to know the business very well so whilst their coding might not be very good their knowledge of what needs doing is very good.
So what can we do to combat this problem? I personally think their should be a small team of people within IT whose job (or one of their jobs) is to develop these small applications. They should work very closely with the end users and not be locked in the ivory tower of IT.
In my current role I’m on the non-IT side of the fence, I have a few quite major applications that needed to be developed so I asked for an install of visual studio and some space on an SQL server. I had my request denied. So I just asked for SQL server space, again request denied (each request taking about a week to go through) So in the end I’m “stuck” in access.
Now these are very nice access apps with version control, comments in the (shock!) and all the other nice things but at the end of the day I was trying to do things the “right” way and ended up being forced down the access route. So when my apps try to get scaled up and I’m quoting a long time for a rewrite who is to blame?
Have you considered looking at SharePoint for department-level applications? Many professional developers will balk at the idea of using Sharepoint for "application development," but it truthfully can be a great way for "power users" to start putting their data and tools in a managed framework.
With SharePoint, you can manage the overall structure of the site and then set up users with elevated permissions within their respective departments. There are some great 3rd-party tools to help with keeping an eye on what's going on in your SharePoint site.
SharePoint is not a silver bullet by any means, but it is great for many multi-user applicatinos that need to keep up with a list of data.
(The following is not really related to my above answer, but your question really hit home and I thought I'd share my similar experiences and insights.)
Our company will be going through a similar process in the near future. I'm on the "end user" side of things and can sympathize with a lot of what Kevin Ross said. Sometimes Access and Excel are simply the best tools available for me to get the job done.
Here's an example: I was asked several years ago to come up with a system for creating Purchase Orders to a vendor in China for product for which there is a 3 month lead time. Our ERP software had a few features for procurement, but nothing that even came close to the complexity of the situation we were facing. Years later, after going through several iterations of the application in Excel (VLOOKUP was a lifesaver), Access ("So that is why people using relational databases. Awesome!), and back in Excel ("let's not make this so complicated"), I still find that these Micorosft Office apps are the best tools to get the job done.
What's the cost to not use these tools to get the job done?
Contract work to our ERP vendor to add a special feature for this ordering process: are you kidding me? We'd likely pay tens of thousands of dollars for an unflexible monolithic application with horrendous user experience...and we would still end up back in Excel.
Buy third party software designed for this exact process: I've seen an on-site demo of software that does exactly what I want for our procurement process. It starts at $100,000. There are probably other tools that we can get for a few thousand dollars, but at that price point, I've already emulated most of their features in my own application.
Try to finish the job "by hand." : Ha! I'm a programmer at heart, which means I'm lazy. If it takes a solid week of sitting at a desk to work up a purchase order (it actually did take this long), you can bet I'm going to work up a solution so that it only takes me a few hours (and now it does). Perhaps the guy after me will go back to doing most of it by hand, but I'll use the tools in my toolbox to save myself time and stress.
It's so hard to find the perfect application to allow for maximum creativity on the user end but still allow IT to "manage" it. Once you think you've found a solution for one thing, you realize it doesn't do something else. Can I write I printable report in this solution like I used to do in Access? Can I write complicated Excel formulas that tie multiple data sources together from different sheets ("You want me to learn what? No, I've never heard of a "SQuirreL query" before. VLOOKUP is just fine thankyouvermuch)? Can I e-mail the results to the people in my department? Can it automatically pull data from our back-end database like I do in Excel and Access? Can I write my own code, VBA or otherwise, to make my job easier? The list goes on.
In the end, the best advice I can give to any IT manager in your situation is to respect the other workers at your company. Let them know their work is important (even if it's only useful to them and the guy at the next desk over). Let them know you are not trying to make their job harder. Don't assume they are morons for creating mission-critical applications in office productivity software; they are just trying to get the job done with the tools at hand and are usually quite capable and intelligent people. Invite them to explore different solutions with you instead of just removing the tools they currently have in their toolbox and then replacing them with ones they don't know how to use.
At the end of the day, if you have users who are smart enough to shoot themselves in the foot by creating complicated apps in Excel and Access, they are probably smart enough to learn to use the appropriate tools to accomplish the same tasks. Invest the time and energy to involve them in the process and you will have a solution that works for everyone at the end.
You could try a hybrid approach: Allow your users to use Excel/Access to home-brew their own, specialized tools, but take the mission-critical stuff and put it under IT control. There are a few strategies that could help you with this:
Make sure that your IT department is firm on VBA. Not the "yeah-everybody-can-write-a-few-lines-of-basic" type of knowledge, but in-depth training, just like you would if it were a less simple programming language. Although "real programmers" will tell you otherwise, it is possible to write large, stable applications in VBA.
If you currently have the data in Access databases, move away from that and migrate it to an SQL Server. This allows you to do centralized backup and management, while still giving your power users the flexibility to "link" these SQL Server tables to their Access frontend.
Commonly used business logic should be under control of your IT department. This can be done either with VBA, by creating an Access library that is linked by your users, or in any of the .net languages, using COM interop. The latter sounds more complicated than it is, and it will increase the satisfaction of your IT department, since developing in .net is just much more rewarding than VBA (version control possible, etc.).
I would second one of Kevin Ross's main points:
I personally think their should be a
small team of people within IT whose
job (or one of their jobs) is to
develop these small applications. They
should work very closely with the end
users and not be locked in the ivory
tower of IT.
I think any IT department that has a lot of users using Access/Excel should have at least one properly trained and experienced specialist in developing apps on those platforms. That person would be the go-between to make sure that:
IT's priorities and policies get properly implemented in the home-grown apps.
the end users get expert help in converting their home-grown efforts into something more stable and well-designed.
I would second Tony's point that whoever works with the end users in revising these apps to meet IT standards should work side-by-side with the users. The Access/Excel specialist should be an advocate for the end users, but also for the IT policies that have to be followed.
I also think that an IT department could have a specialist or two on staff, but should also have a full-time professional Access and/or Excel developer as a consultant, since the on-staff people could probably handle day-to-day issues and management of the apps, while the professional consultant could be called in for planning and architecture and for the implementation of more complex feature sets.
But all of that would depend on the size of the organization and the number of apps involved. I don't know that it would be desirable to have someone on salary who is nothing but an Access/Excel specialist, precisely because of the problem you get with all salaried employees compared to consultants -- the employees don't see as wide a variety of situations as an active consultant with the same specialization is likely to see and thus the consultant is going to have broader experience.
Of course, I recognize that many companies do not like to outsource anything, or not something that important. I think that's unwise, but then again, I'm the person that gets hired by the people who decide to do it!
If it's mission critical, and it's in Access or Excel, is built poorly, and no one understands it, it is probably time to rebuild it properly.
When the 'users' are in control it usual means one particular person is in control of the architecture, design, coding and documentation... except they normally omit the documentation step. Source control and bug reporting, the touchstone of software development, is usually absent. Few instances of code reuse, due to the nature of Office apps (code modules usually embedded into documents) and VBA (little OOP, most VBA coders don't use Implements, etc). All this means that the resulting applications are not subject to get proper scrutiny and quality can suffer, meaning there are likely to be maintenace issues, escpecially when that one user leaves. I know because I used to be that person ;)
So in order to satisfy the IT department, the proper process needs to be applied. That one 'power' user can continue to own the design and coding but will get peer review, perhaps the serivces of a technical author and a dedicated tester, be required to use source control, perhaps consider integrating with enterprise systems, etc.
There is no getting around the use of Excel/Access. It's what's available, and still very powerful and flexible. The best thing to do is offer some guidelines as to how files should look and be set up. If everyone is using similar standards then the files will live longer and more productive lives, beyond the creator's tenure at the company.
You've got some excellent answers regarding dealing with the folks and the business side of things. So my response will be more technical.
If you are going to redesign the app have the developers work in the same offices as the users. Given the users updates every day or two. If the users have any minor suggestions give those to the users within a day or two. Ultra Frequent Application Deployment
Give the power users an Access MDB/ACCDB linked to the tables with a bunch of starter queries. Let them create the queries they need to export the data to Excel for their own purposes and distribution to clients.
What open source toolkit does fatwire compare to and are there some particular advantages to fatwire?
How hard is fatwire to export out of and move to a free alternative?
How stable is it as a platform to write java extensions on?
From a development persepective, FatWire can be unfriendly. Having worked on a number of sites using this application it can easy bloat, and become difficult to maintain.
From a user perspective there has been alot of effort in the UI and this has led to a highly functional tool.
From a client perspective all clients bar 1 (a large news agency) were happy with the end result. FatWire can slow when using complex logic to generate menus or breadcumbs for example or when you have a large amount of content. This is the main reason the one client was unhappy. The FatWire site regularily struggled under the load. It sometimes seen as a solution to all web needs.
As such FatWire succeeds in serving Static Content & Semi Dynamic content, but can flounder when forced to do fully dynamic sites (from my experience).
From the original press release:
FatWire Software announced the rollout
of FirstSite, which is a set of tools
and best practices that helps
companies using FatWire Content Server
get their first Web site or
application running quickly while
providing a foundation for future
expansion. FirstSite includes a
collection of standard templates and
site components that are common to
most sites, combined with
documentation, training, a rich
developer community, and best
practices methodology. FatWire and its
solution partners are using FirstSite
as the basis for developing
content-centric applications for
specific vertical markets. With only
minor, cosmetic alterations,
developers can use the code in
FirstSite to implement a first site,
while simultaneously learning how to
utilize Content Server's capabilities,
such as dynamic content delivery,
personalization, caching, and product
catalogs.
Firstsite is not a product, unless this has changed since 2004 (unfortunately I cannot look, since their developer site is down). Fatwire's Content Server does not compare to any Open Source CMS that I know. It's scope goes much further. I will answer your questions one by one:
Advantages - There are many (or nobody would buy it, and it is not cheap)
On the delivery side: scalability, fine-grained cache control, stateless servlet architecture, ....
On the back office side: virtually no limit to asset types, dynamic content attributes, find-grained security and access control, ...
On the development side: Intelligently architected API with good coding productivity, tag library, ...
Openness
You cannot easily expect to migrate content between any two CMS products, open source or not. While there are ways to extract contant from the database in XML and other forms, using product tools, or simply at the database level, I don't think that this can be an argument for or against using a particular CMS. Ever tried to migrate from Drupal to Joomla?
Stable
I worked on several Fatwire implementations from 2000 to 2004 (back then it was OpenMarket Content Server, then Divine Content Server). It was stable enough for the Washington Post, the New York Times, and the S&P sites, and I would expect stability not to be an issue today.
Fatwire is really unique concept from developer point of view. It builds everything on a very abstract, extremely flexible clever asset modeling framework which is stored in relational database.
Application logic is based on "templates" which actually are pieces of JSP code. This JSP code is not like conventional Java, but tags instead. It takes very long from a developer to learn these tags and Fatwire asset api. Expect even months before skilled develpers start to be productive.
Almost nothing useable samples ships along the product. There is advertized "FirstSite" but it is way too simple for the purpose this product is used normally (huge complex sites). So pretty much everything has to be built from scratch.
Cache control is advertized to be one powerful feature. Yes it is, but we had extremely long learning curve and it never worked exactly like one assumed.
Wysiwyg editing has been missed from this product even it is advertized. At least during 2009 it had serious conceptual problems which practically prevented using it in live environments. But it was cool feature for demos and marketing of course. Today it might be fixed.
As a summary and if I were a customer with limited budget, I'd select any open source alternative instead. Mostly because development costs with Fatwire are high due the uniqueness of the product, lack of good documentation and extremely long learing curve. Of course the product price tag is also thing to consider.
And to answer to questions: you have to start from scratch if you move from Fatwire 6.0 to any open source alternative. And it is stable to build Java extensions on.
Fatwire stores content in relation database and file system. Depending on what type of content (structured/unstructured), Fatwire can be evaluated.
I like to post links to Secunia search results to demonstrate (in numbers) how insecure a certain CMS (or blogging software) is.
See What are some of Drupal's shortcomings?
But there was an interesting comment to this answer:
Eaton:
It's also important to note that
Secunia only publishes vulnerability
reports that are explicitly announced.
I've worked with other CMS packages
that tuck important security fixes in
minor releases with no announcements
at all. Drupal has a 15 person secteam
that reviews core and all 3500 addons
and officially announces the security
patches, no matter how minor, as a
matter of policy.
Are there any studies or articles which take this into account when comparing Content Management Systems?
I have a small number of articles bookmarked (like this one by my coworker), but they're almost all by people defending their CMS of choice from accusations of poor security. (My own comment in your post included!) One of the difficulties is that I don't think anyone has ironed out what constitutes a 'reasonable comparison' -- everyone gets annoyed at a bad comparison, but wanders off before anyone can determine what a level playing field is.
A couple things stand out that most "quick overviews" miss:
The security policy of the product's dev team
The presence of a specific person or team (depending on the project's size) responsible for security. Everyone on the project should care, obviously
Are there documented security best practices for third-party developers
Comparison of vulnerabilities by type and severity
Perhaps this thread would be a good place to brainstorm what WOULD constitute a good comparison study?
Update - A colleague has had the opposite frustration with Secunia: inaccurate and erroneous reports filed by third-parties against an OSS project. Secunia refuses to update or amend them, apparently. It's a useful service or announcements, but everything I hear makes me cringe at using them for comparison.
The other major problem with using those Secunia searches is that they include all contributed modules along with Drupal Core even when the particular announcement even though a particular security announcement might be for a module that's used by about 30 people.
In addition to vulnerabilities by type and severity, you also need to take into account "core" vs. "add-on" modules and the practice of occasionally putting multiple vulnerabilities into a single announcement (happens often).
My feeling is that some of Eaton's measures on policy are more important than specific numbers or severity of vulnerabilities.
The last good measure I would add to that list is months in the past X years where a vulnerability was publicly disclosed without any fix from the project. That's rare, but is a sign of a truly failed security process.