I have a question to people who are writing programs in Domino Designer. I don't like it, really and I'm searching how to write apps for that platform in Intellij? Does somebody have experience in moving project from DDE to IntelliJ? I wan't to do this because my actual projects doesn't use XPages for front-end.
Thanks for answers!
This is simply not possible. A majority of the design elements needed for NSF- Development are stored in a proprietary binary format. There is no way to edit them in any other program than the Domino Designer.
You need to get familiar with this tool or abandon Domino development completely.
I am a javascript/html developer that hasn't ventured into visual studio much, so this might be a trivial question.
I am currently developing a Windows Store app (winJS), that will likely turn into several apps. And it would be highly likely that I will be reusing code, so I have made a js library with the common code.
The question is, how can I develop on this lib in visual studio, so that the apps that I am developing will use the latest version of it (i.e without me having to copy the files in again manually).
Best thing I can think of is, create a new project for the lib, and include it in the applications solutions, but what type of project would it have to be, and how to you expose the files?
Hope that makes sense!
Thanks!
I usually solve this by having the project copy the JS files I want to a common location, and add that file to the target project using a LINK to the file I want to include, rather than just adding it -- this is on the "Add Existing File" dialog, under the little arrow on the "Add" button.
VS 2012 doesn't have a JavaScript library project type. You'll have to manage your library as loose files.
The easiest thing would probably be to create a nuget package. That way it would be easy to pull into other projects and have the tool help keep you up to date. It does have the downside of needing to put your stuff into a nuget feed, which is not something you want for private stuff.
In the example section in extjs4 official site, the source code is clean and direct (on a single page). However the ext designer uses MVC architecture that I am quite confused.
If I want to create UI using extjs 4, for multiple page, am I supposed to create multiple projects in ext designer?
I think these are two seperate questions '1. should I use MVC' and '2. Why does Designer NOT use MVC'.
In my opinion that answer to 1. should be 'yes' unless you project is relatively small and you feel comfy managing the entire codebase in one long file. This quickly becomes unmanagable and there is a lot of searching needed to locate the section you're after.
The answer to 2. is that designer is aimed to provide designers (funnily enough!) who often won't have any coding experience the ability to create prototypes and templates that developers can pick apart and build into applications. At least that was true with designer version 1.
I believe designer 2 is aimed much much at being able to directly port code into applications but if you're talking about version 1 I think you will need to take the code generated by the designer and move it into an MVC style structure in order to build applications which are anything more than a couple of simple pages.
I'm trying to create a setup project and I can't believe how painful it could be. Non of the tools that I've tried to use, haven't satisfy me.
How come? Well, let's see:
First and easiest option: Setup project built in Visual Studio. Easy and fast. you can easily implement custom actions, even if you're code was written in c# or vb.net. Exactly what I wanted. But this approach has some drawbacks and the major one is unbelievably painful way to implement custom dialogs. For example if I need to ask for DB credentials, authorize the user and proceed with the rest of installation. But no. There is no way to build custom setup dialog in VS. Actually there is a way, but it's not an easy one. I mean what, are you kidding me? I have to spent a day to create a couple of simple dialogs?
Second option: Use some kind of a tool. Like InstallShield. You have to pay for it, yes, fortunately it's damn cheap. Only $5500. Not a big deal, right? Well maybe, but for me it's like "dude, forget about it"
Third option: Use WIX Nice, has many options. Not so easy to use like the one built-in VS but has many much better features. The only problem - I spend a few hours trying to convince that thing to run my code written in c#. I failed. Nothing helped and I give up.
Now. Please, please my fellow experts, all knowing developers. Help me. What should I do? What's the best way to solve my problem (believe me my boss will kill me, he likes to achieve results over dead bodies of his employees).
Tell me is there any better way to edit .wid files. Using Orca tool, isn't an easy solution.
Or show me a real example of setup project built with WIX which can run managed c# code.
Thank you!
I implemented a custom dialog by simply displaying a form in my custom action. This is a straightforward thing to do.
I don't suggest using either "Setup Projects" ( aka Visual Studio Deployment Projects ) or Managed Custom Actions ( in your context you are referring to InstalUtil custom actions ).
For managed custom actions I use Windows Installer XML - DTF ( Deployment Tools Framework ). This builds and packages your CA to look and feel to MSI like a C++ CA which means you can then consume it using InstallShield, WiX, Wise and so on.
I also don't suggest using CA's as fake dialogs. If you want a fancier UI write an external UI handler ( not a simple task ). I suspect your real problem though is that VDRPOJ doesn't expose this very well, that WiX is lot's of writing in XML. InstallShield gives you a drag drop IDE for working on custom dialogs. But then that would be one of the many reasons it isn't free.
What are the software/ Wiki you use to write and share your specs about the developers, testers and management?
Do you use Wiki system, and if so, what Wiki software you use?
Or do you use Sharepoint to manage and version the specs? One problem with SharePoint 2003 as specs platform is that it's very hard to collaborate among different people.
For backward compatibility sake, I would also like to have the platform able to import Microsoft Word seamlessly. And it would certainly help if the interface is similar to Microsoft Word.
Any idea?
I've used Confluence at a number of places, it's a pretty powerful wiki and very good for creating specifications that can be shared amongst various parties. See:
http://www.atlassian.com/software/confluence/
There's some more information here on the advantages of using Confluence:
https://stackoverflow.com/questions/170352/confluence-experiences
EDIT: I've updated this to deal with the Microsoft Word import feature you mentioned. Confluence supports this through the Office Connector here:
http://www.atlassian.com/software/confluence/plugins/office-connector.jsp
There's also a Sharepoint connector:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
plus a whole bunch of plugins:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
Some of these are user contributed also. I can't recommend Confluence enough as a commercial wiki.
I've also used JSPWiki, which is open source. it's ok but not as good as confluence, see:
http://www.jspwiki.org/
You could try Google docs - I have successfully used this in the past. It supports import / export to MS Word, and it has great support for multiple user - see http://www.brighthub.com/internet/google/articles/8236.aspx.
It supports versioning, allows you to chat with other people who are currently working on the document, and shows you a list of all the changes others have made to the document (without needing to close / reopen the document).
If you want corporate support, Google also provides that - see Google Apps for business.
We use SharePoint -- it's not ideal, but it does a decent job. If I were you, I would seriously look at getting off SharePoint 2003 and on to MOSS (SharePoint 2007). It's not perfect, but it's substantially better. Here's a little bit on using MOSS as a wiki. I think in general wiki's are a good tool for getting people up to speed on your system. We used to pass around "getting started documents" and now we have all that type of stuff in our developer portal.
Per John's comment, I looked up this feature comparison. I have to go back and look at what features I'm using that are not in WSS -- I might be paying for licenses I don't need! :)
We use email. I know it isn't elaborate, but it is easy to use. Everyone has it installed and there are no licensing issues. All spec changes are sent to an super set email distro indicating the updates and the location on the network share where the spec can be found.
We use Alfresco, in its Community version, from both its Share and Explorer web interfaces.
Quite useful, with a document library, wiki, forum and calendar.
We curently host about 1.8 Go consisting mainly in docs, versionned and sometimes automatically converted to PDF (by creating an automatic content rule).
FTP, WebDav and network share are also used to access to the same repository.
You could take a look at Microsoft Groove - the collaboration software that Microsoft bought a few years back.
It's bundled free with premium versions of Microsoft Office.
You can customize the workspace with discussion boards and can fairly seamlessly store collaboratively-edited Office documents.
We use MediaWiki for dos & specs. Wiki definitely wins anything like Microsoft Word or SharePoint - it allows you to develop a documentation in "first refer, then describe" = "divide and rule" way. Perfect for developers - they used to think the same way. The process of developing a documentation is almost ideal: you start from TOC and drill down until you write the document for every link you put earlier.
MediaWiki is quite customizable - there are lots of extensions there. The most necessary ones are:
Source code highlighter - CSO_Source
Our own templates integrating wiki with class reference.
Others are InterWiki, FileProtocolLinks, YouTube (we use customized version of it to display HD video), ReCaptcha, SpecialDeleteOldRevisions, Maintenance.
Some integration examples are here.
And we use Google issue tracker to track the issues. Its main advantages:
Imput usability: the process of adding\changing the issue is really convenient there. Earlier we tried Track Studio - the same actions require 2-3 times more time there, so it died fast simply because most of us hated to use it.
Customizable grids. See the examples. Really helpful.
Atom\RSS support. So everyone knows what's going on.
There is a Gurtle tool integrating it with TortoiseSVN. Really helpful.
Its main disadvantage is that it can't be closed from the public access. This makes it simply unusable in many cases.
If you want a UI similar to Word, why not use Word with SharePoint 2007? You're on 2003 so the experience is there. Upgrade to SharePoint 2007 and you can have the collaboration, Word features, document sharing, and so on.
This is the kind of thing Microsoft wants people to use Office for, so there's a ton of doco out there about how to configure your SharePoint and Office environment to support collaboration.
There is something that Google do in this direction and it looks really cool: wave.google.com. It would be a great step in collaboration and worth to wait it.
Here we use Google Docs it makes the documents available to everyone write or read only, public or private among people that have or not Google accounts, it also can import Word docs, not to mention that it runs directly into the browser so it has high availability with zero cost and zero setup, also its computer/OS agnostic, we have a nice experience with it.
Also perhaps you should take a look at Basecamp or Backpack at 37Signals, any of then might also fit your bill.
We use DocBook for all of our specifications (and other customer-facing documentation). DocBook is an XML format that lets you easily generate documents in just about any format, including PDF, which is how we distribute things to clients to get them signed off. We can divide a document into files (by section) and commit everything to our source control system (Subversion). Because it is all XML (i.e. text-based), Subversion's automatic merging and conflict resolution works great if two people work on the same file. We have a set of stylesheets that all of our documents use, so all documents share the exact same style/format, with no extra work on our part.
And if you don't like editing XML files directly, there are GUI front-ends that provide a reasonably WYSIWYG-like experience. I believe that most people in my office use XMLMind. Still, we happen to all be technical people so if we had to write XML directly it wouldn't be an issue.
As a sidenote, we also put out release notes. We have some XSLT that lets us write documents like this:
<bugs>
<bug id="1234" component="web">JavaScript error when clicking the Kick Me button</bug>
</bugs>
We then have a script that runs through our Subversion repository doing an svn log from the previous release tag to the current release tag, and some Bugzilla integration to automatically generate release notes on-the-fly.
(also, for most internal-only documentation, we use MediaWiki, which is also a great way to collaborate.)
We use OnTime. It was originally only used for defect tracking, but we've started using it to track features as well. These can be used to document the feature as it evolves during development. Features can be grouped together into sprints or releases, and time can be tracked against each feature. If you are using SCRUM, you can also plot burn-down charts for each sprint. It also has wiki functionality.