We currently use FogBugz at work, and I'm using the URLTrigger plugin to call out to a CGI script every time a case is changed. I'm trying to figure out how to do something similar with Trac; does anyone know if this is possible? I can't find any plugins or discussion on it.
t-h.o is the first address to seek for Trac plugins. Because Trac is actively encouraging plugin development by it's sophisticated Component Architecture since early days, you'll find a lot of code. And since Trac core developers have been involved, this is often quite good code quality too. Stuff you'll read to get an idea on how things are supposed to work.
Maybe you'll want to start with current official wiki docs to dive into Plugin Development for Trac and change over to trac-hacks.org afterwards.
Regarding your declared development goal especially look at trac.ticket.api.ITicketChangeListener - an extension point interface for components that require notification on when tickets are created, modified, or deleted. Sounds like this is just what you want.
You'll need to (rough list of requirements)
create a class based on trac.core.Component that
implements (ITicketChangeListener)
provide modules exactly as required by the interface definition
If you need more details, I'd recommend to look at the DefaultCcPlugin source. There are many more plugins implementing the ITicketChangeListener interface, but this is a rather small plugin, that'll just show you the available methods and not distract with too much functionality around them.
Add information to your question as you progress, or Comment here as required. I'll try to guide you further on to the best of my own knowledge.
Related
I have recently built my own plugin for Glimpse to see all my Couchbase traffic, and would love to see statistics on what is going on in Autofac. Is there any work being done on an Autofac plugin for Glimpse? All I can find is the one from three years ago, but I don't think it shows a whole lot of detail.
Ideally what I would be looking for would be a full plugin that can do timings also, to measure the performance of Autofac using Glimpse and work out how much time is taken to resolve instances to isolate potential performance bottlenecks.
Has anyone done something like this? If not, does Autofac have hooks we could hook into to capture that stuff and log it?
I'm not aware of anyone who is currently creating a Glimpse extension for Autofac.
As you mentioned, there is an extension out there now, but it might not be as detailed as you'd like.
All that said, it seems like Autofac's Activation Events would make it pretty simple to create a new Glimpse extension to expose some of the data that you're after.
For timings, if you are using an IServiceLocator in MVC, you could also create a GlimpseServiceLocator which uses a Stopwatch to get timing information.
I am seeking a way to allow my non-tech users to specify a workflow and execute it (if anyone is interested, I want them to specify and execute test cases). Visual programming seems a good way to go.
Can I modify the Scratch IDE to remove some categories (such as sound, motion, etc), and add some of my own? Ditto for individual keywords (obviously, I then need to handle new keywords).
I have Googled, but the answer is not immediately apparent.
[Update] I have just found Google's Blockly
Blockly was influenced by App Inventor, which in turn was influenced
by Scratch, which in turn was influenced by StarLogo.
It looks very promising. Especially when it says
Exportable code. Users can extract their programs as JavaScript, Python, PHP, Dart or other language so that when they outgrow Blockly
they can keep learning.
Open source. Everything about Blockly is open: you can fork it, hack it, and use it in your own websites.
Extensible. Make Blockly fit with your application by adding custom blocks for your API and remove unneeded blocks and
functionality.
One possible snag is that it is browser based, but if my management don't like that, then I can create a dummy Windows based app consisting of little but a TWebBrowser component.
I will investigate and report back - unless someone else posts an acceptable answer first.
The short answer to your initial question is: no. You can't customize Scratch, or not to the extent that you seem to ask/want.
That said, look at:
custom blocks.
scratch extensions.
variants like snap
using scratch's source code in squeak to make your own variant.
other systems inspired from scratch, like appinventor and blockly.
Only the first two are compatible with the scratch web site.
A word on the site: depending on your purpose with Scratch, the exchange between users is a powerful part of scratch. Check how cooperation is supported, like the backpack. There's also a good wiki that documents much of the above.
Do you know of a workflow that includes source maps for an app compiled with grunt?
I am well aware of plugins like uglifyjs that allow you to simply generate a source map. But I'm looking for incorporating this into a more complex workflow, rather than just making a one-off source map.
I've noticed that the most popular Yeoman generators (that I know of) are missing source maps in their workflows. Is this just because of a lack of support in the major plugins for source maps? Or is it instead that source maps aren't necessary in work flows, and I just can't think of a clever enough alternative?
Notable sources of trouble with popular grunt plugins that I've run into include:
uglify being unable to handle even the most basic of project structures without a hacky fix.
usemin also being unable to handle source maps beyond the simplest of configurations, in that it can really only support one per project (but still requires a hack to correct it). A possible solution is obviously to stop using usemin altogether, but then you lose out on all of the benefits of it, like pairing it with rev, watch, and connect.
I'm thinking that my best course of action might be testing with un-concatenated/not-minified sources when I'm testing my app. This is, of course, less than ideal, as I'd like my test environment to mirror the production one as best as possible.
Do you use source maps in your grunt project? How do you do it? If not, how do you get around the lack of support for them?
Updates 02/17/14
Z Goddard and I are working on fixing up source maps across the grunt-contrib suite. The planned options for the entire suite can be read about in this repo. We're also working on a new library, sourcemap-util, that will provide helper functions for generating source maps with any library. I'll update this when there's more progress.
I've done enough research to now be able to answer my own question.
No, there is not really any good way to handle source maps right now with grunt.
Both usemin and grunt-contrib-uglify need updates for this to work as I'd like. I submitted a pull request to grunt-contrib-uglify that is a good start on better source map support. With luck, this pull will be merged.
As for usemin, I disagree with its approach to handling dependencies. I've begun a separate project, grunt-resourceful, that goes about things differently. That project is still in its infancy, so I don't suggest using it now. I'll update this once 1.0.0 is released.
How easy it's to come up with a drag and drop web-based interface that'll provide me features to wire objects together, setup configurations nicely in a modal window for each object? I'm looking for links that've any similar kind of interface, or articles on this. also, i'm looking for your technology/language suggestions.
Another way I'm thinking - as a desktop appln + browser dependent addon..
Is it good to create such an user-interface using XUL, which can be deployed as an addon on Firefox/as a stand-alone application in Windows? Are there any other similar things/technologies which can provide a basic framework for us to build on it further?
Why do I need this, finally?
..for building simple Workflows, for defining process flows, that can provide me some auto-generated xml content which I can use for further processing.
Thanks!
I'm quite interested in this, too.
I've flirted with HTML5's DragDrop implementation - Quirksmode has Bad Things to say about that, so then I thought "Perhaps a JavaScript library can help me" - haven't checked out jquery for this yet, but I have checked out YUI's DragDrop, DragDropManager and DataSource, and its looking hopeful (consistent, reliable).
I tried things like adding an iframe on the fly to any document, to provide this kind of functionality without needing to add dependencies to the page given the iframe - mixed results, but in my case I was trying to cater for x-domain access, which proved difficult.
So I'd say JavaScript could be a winner - if designed poorly it could be difficult to manage resources though, if you want to potentially DragDrop/edit/config any element in a document - so watch out for that.
If you're keen and able, Adobe AIR apps also look promising - but I can't help with any more info on that, other than they're Desktop Apps with great flexibility.
I'ma going to keep an eye on your Question, I look forward to any other Answers/comments!
EDIT: I forgot to mention Flex (aka Flash Builder 4, latest version) is quite easy to create stuff like this, though I've had exposure to Flash for a while. It comes with the standard Adobe caveats; price, libraries, support.
I'm planning on starting a new project, and am evaluating various web frameworks. There is one that I'm seriously considering, but I worry about its lasting power.
When choosing a web framework, what should I look for when deciding what to go with?
Here's what I have noticed with the framework I'm looking at:
Small community. There are only a few messages on the users list each day
No news on the "news" page since the previous release, over 6 months ago
No svn commits in the last 30 days
Good documentation, but wiki not updated since previous release
Most recent release still not in a maven repository
It is not the officially sanctioned Java EE framework, but I've seen several people mention it as a good solution in answers to various questions on Stack Overflow.
I'm not going to say which framework I'm looking at, because I don't want this to get into a framework war. I want to know what other aspects of the project I should look at in my evaluation of risk. This should apply to other areas besides just Java EE web, like ORM, etc.
I'll say that so-called "dead" projects are not that great a danger as long as the project itself is solid and you like it. The thing is that if the library or framework already does everything you can think you want, then it's not such a big deal. If you get a stable project up and running then you should be done thinking about the framework (done!) and focus only on your webapp. You shouldn't be required to update the framework itself with the latest release every month.
Personally, I think the most important point is that you find one that is intuitive to your project. What makes the most sense? MVC? Should each element in the URL be a separate object? How would interactivity (AJAX) work? It makes no sense to pick something just because it's an "industry standard" or because it's used by a lot of big-name sites. Maybe they chose it for needs entirely different from yours. Read the tutorials for each framework and be critical. If it doesn't gel with your way of thinking, or you have seen it done more elegantly, then move on. What you are considering here is the design and good design is tantamount for staying flexible and scalable. There's hundreds of web frameworks out there, old and new, in every language. You're bound to find half a dozen that works just the way you want to think in your project.
Points I consider mandatory:
Extensible through plug-ins: check if there's already plug-ins for various middleware tasks such as memcache, gzip, OpenID, AJAX goodness, etc.
Simplicity and modularity: the more complex, the steeper the learning curve and the less you can trust its stability; the more "locked" to specific technologies, the higher the chances that you'll end up with a chain around your ankle.
Database agnostic: can you use sqlite3 for development and then switch to your production DB by changing a single line of code or configuration?
Platform agnostic: can you run it on Apache, lighttpd, etc.? Could you port it to run in a cloud?
Template agnostic: can you switch out the template system? Let's say you hire dedicated designers and they really want to go with something else.
Documentation: I am not that strict if it's open-source, but there would need to be enough official documentation to enable me to fully understand how to write my own plug-ins, for example. Also look to see if there's source code of working sites using the same framework.
License and source code: do you have access to the source code and are you allowed to modify it? Consider if you can use it commercially! (Even if you have no current plans to do that currently.)
All in all: flexibility. If I am satisfied with all four points, I'm pretty much done. Notice how I didn't have anything about "deadness" in there? If the core design is good and there's easily installable plug-ins for doing every web-dev 3.0-beta buzzword thing you want to do, then I don't care if the last SVN commit was in 2006.
Here are the things I look for in a framework before I decide to use it for a production environment project:
Plenty of well laid out and written documentation. Bad documentation just means I'm wasting time trying to find how everything works. This is OK if I am playing around with some cool new micro framework or something else, but not when it's for a client.
A decently sized community so that you can ask questions, etc. A fun and active IRC channel is a big plus.
Constant iteration of the product. Are bugs being closed or opened on a daily/weekly basis? Probably a good sign.
I can go through the code of the framework and understand what's going on. Good framework code means that the projects longterm life has a better chance of success.
I enjoy working with it. If I play with it for a few hours and it's the worst time of my life, I sure as hell won't be using it for a client.
I can go on, but those are some primary ones off the top of my head.
Besides looking at the framework, you also need to consider a lot of things about yourself (and any other team members) when evaluating the risks:
If the framework is a new, immature, "bleeding-edge" framework, are you going to be willing and able to debug it and fix or work around whatever problems you encounter?
If there is a small community, you'll have to do a lot of this debugging and diagnosis yourself. Will you have time to do that and still meet whatever deadlines you may have?
Have you looked at the framework yourself to determine how good it is, or are you willing to rely on what others say about it? Why do you trust their judgment?
Why do you want to use this rather than the "officially sanctioned Java EE framework"? Is it a pragmatic reason, or just a desire to try something new?
If problems with the framework cause you to miss deadlines or deliver a poor product, how will you talk about it with your boss or customer?
All the signs you've cited could be bad news for your framework choice.
Another thing that I look for are books available at Amazon and such. If there's good documentation available, it means that authors believe it has traction and you'll be able to find users that know it.
The only saving grace I can think of is relative maturity. If the framework or open source component is mature, there's a chance that it does the job as written and doesn't require further extension.
There should still be a bug tracker with some evidence of activity, because no software is without bugs (except for mine). But it need not be a gusher of requests in that case.