Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
How to know that, the system you are building is a better as Desktop Application than an Web Application?
My top 3:
I need to use/control the hardware directly (printer, graphic card...).
I don't care if my project is platform dependant.
Need complex user interface (OK Web 2.0 is better than ever, but it's still hell to make advanced specialized stuff to work in all Web browsers).
Interesting question. in practice the answer hinges primarily on the deployment requirements:
If you want very broad and "instant" deployment - then use HTML and HTTP.
if you or your organization have administrative control over the computers on which the app will be deployed, making it a "desktop app" is acceptable.
Most apps lie between those extremes.
It depends on your target audience, desired features, and what delivery method makes the most sense.
It might help to answer these questions:
1) Who will use this?
2) What will they do with it? (think about thinks like media operations, data storage,..)
3) How will they best be able to get this app?
4) What operating system(s) will it support?
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 7 years ago.
Improve this question
First and foremost, I would like to say I am very, /very/ new to programming and the like. If I decide to build this, this would probably be my first "large" project i've ever done myself.
What I am looking to build is a very simple Chat/IM client to use for the users in our office network. It would just call us their Windows logon name and use that to IM and the like. I'm talking a very simple client, with a list of names of people who are logged into the network, and option to IM them and an option to do a multiple user chat. It doesn't have to be visually stunning.
How difficult would this honestly be? Is it possible for me, someone who has very little knowledge when it comes to programming to teach myself how to build it?
If not, can you explain why this would be very difficult and what already built clients would work well for what I am using?
This is a big application. Your first parts will suck and refactoring it later will suck even more. I suggest building something small in the first place and then step from one bigger project to another.
XMPP/Jabber is IMHO the best solution for office IM. Most clients like Pidgin, Adium etc can connect to it. Every bigger company I worked for in the last years used it. Take a look at Openfire - A free open source XMPP server that you can directly connect on and which is easy to set up: http://www.igniterealtime.org/projects/openfire/
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 6 years ago.
Improve this question
I'm new with zigbee i need you to help me learn about it and know how to implement an embedded system using it
thanks in advance
One good place to look is on the Digi site. They have several products to help you, including embedded development kits.
If you want to go Open Source, look at Source Forge. They have some open source stacks. I have not used any of them, so I cannot comment beyond knowing that they exist.
Depending on your needs, you might want to just look at XBee, which is a subset of zigbee. There are some nice development tools for XBee. I have used an XBee expansion shield with the .net micro framework and boards provided by TinyCLR to do a wireless prototype.
Creating a zigbee stack on your own would be a fairly large task, so only you can determine if there is ROI in doing so. I would be more inclined to buy it in.
Get a ZigBee Starter Kit. Lots of vendors provide one; gust Google that exact phrase.
For example: AVR 8-Bit RISC - IEEE 802.15.4/ZigBee - Tools
Or you can ZigBee on a PIC/Microchip at very low cost. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2112
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
I work for a insurance company. We have our own development department made-up of almost 150 people plus some providers (outsourcing and custom made apps pretty much). In our company my team have made what we call non-functional logic libraries. That is, software libraries to handle things that are horizontal to all the development teams in our department, e.g. Security, Webservices, Logging, Messaging and so on. Most or these tools are either made from scratch or adaptation of a de-facto standard. For example our logger is an appender based on Log4J that also saves the logging messages into a DB. We also define what libraries to use in the application, for example which framework for webservices to use. We use pretty much JavaEE and Oracle AS in all our organization (with some Websphere Application servers).
Much of these projects have their architecture documented (use cases, UML diagrams, etc) and generally the generated documentation are available.
Now what we have seen is that for users sometimes is difficult to use the the libraries we provide and the are constantly asking question or they simply don't use them.
So we are planning to generate a more friendly documentation for them, so my question is:
What are the best practices or the checklist that software documentation should have?
Something comes to my mind:
API Reference guide
Quick start Tutorial
API Generated Documentation.
Must be searchable
Web Access
What else should it have? Also, based in your experience what is the best way to maintain (keep it up-to-date) and publish this type of documentation?
Keep your documentation in version control too.
Make sure on every page it has a version number so you know where your user has been reading from.
Get a CI server going and push documentation to a LIVE documentation site upon updates.
Do documentation reviews like you would code reviews.
Dog-food it :)
Kindness,
Dan
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
I am developing an application that can be extended using "plug-ins". The plug-ins will be pretty basic, allowing developers to add new "actions" to my application.
What documentation/information do I need to provide so that developers can do what they need to?
I was thinking a short example and a general overview of how the application/plug-ins work?
You need to foster a sense of community. Things like:
sample code for more than one real plugin;
a getting started guide for plugin writers;
details on how to deploy a plugin and on how they are discovered by your application;
a wiki so that plugin writers can collaborate, and
an easy way for plugin authors to contribute their plugin
might help.
You also have to decide how detailed your API is going to be. IF you are offering a rich API, make sure to document it well, and to explicitly highlight directives (explicit "do" or "don't do" instructions).
Most users will not bother to read the documentation and figure out things from the name, or skim your docs. So it is best if you can avoid "surprising them", and if not, at least offer them a chance to find the problems.
Finally, err on the side of caution with checking correct use and send exceptions rather than counting on users meeting your instructions.
Also, think very well in advance on whether you truly expect anyone to use your plug-ins because the core product becomes a "hit".
It is very common to err on the side of optimism, and think that when you are writing a plug-in infrastructure that somebody will actually use it.
However, nobody is likely to write plugins before the core out-of-the-box offering is successful and popular. You may be better off publishing and distributing your own plugins before worrying about extensions by others.
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 5 years ago.
Improve this question
Where is a good place to start with making an application in .NET that communicates through OPC?
You can find a good article and a library to start with here: http://www.codeproject.com/KB/COM/opcdotnet.aspx
The Code Project article is from the early days of .NET and may not be the best option today.
Alternatives include OPC Foundation's own .NET API (requires OPC Foundation membership) or several commercial products. OPCconnect.com lists a number of these.
Be careful. I haven't used an OPC API yet that properly conforms to any sort of calling conventions, particularily in the area of freeing memory (COM, as documented, or otherwise). Expect a month of debugging memory leaks.
SoftwareToolbox's OPCData.NET (http://www.opcdata.net/) claims to be a 100% Managed code solution for OPC Client. SoftwareToolbox also has some other OPC libraries to help with binding OPC data to forms and web interfaces.
If buying a comercial toolkit is an option I've used the Northern Dynamics server toolkit and it worked fine. A toolkit will take away a lot of the issues mentioned in the other questions (or at least you should get support if there's a problem).
They've wrapped the OPC protocol up nicely so it makes it easy to use. See one of my questions here for a type-safe Variant wrapper that I wrote to help with this.