There are two different organizations linked to reactivex.io:
https://github.com/ReactiveX
https://github.com/Reactive-Extensions
I see that Java extensions exist only in ReactiveX.
But, Rx.NET or IxJx exist in both organizations. However the former is active in Reactive-Extensions and the latter more active in ReactiveX.
Why there are two different organizations?
ReactiveX is the repo created for RXJS 5 which is a ground-up rewrite of RXJS for performance purposes.
You can find more details about the changes between the two versions here. My guess is that Rx.NET isn't on ReactiveX yet because they aren't on version 5 yet. It also seems like the various languages are pretty loosely coupled and don't necessarily work too closely together on things like this.
Some source issues discussing this:
https://github.com/Reactive-Extensions/RxJS/issues/1029
https://github.com/Reactive-Extensions/Rx.NET/issues/307
https://github.com/ReactiveX/rxjs/issues/1979
Related
These are more high level questions, but our team is new to developing with APEX. We are currently a team of 3. We are using APEX 19.2, but are planning to upgrade up to 21.1
How do others handle the development flow, versioning, and releases of their projects when working in APEX?
We put majority of the business logic (validations, source sql, and process handling) in packages. So I feel it is pretty easy to version those files as they are outside of the APEX UI and can version in Git accordingly, but how do others version control all the APEX UI changes (pages, regions, items, DAs, etc...)?
I've searched and haven't really stumbled upon best practices of how teams, that use APEX, conduct their development process. One thing I'm nervous about is branching changes inside APEX UI. Sometimes we are given a requirement (say A) and we are asked to hold that release, but start working on requirement B. We may even release B before A gets final approval.
Are there any best practices, to ensure that developers working in the same workspace do not collide with others work? Luckily most of our project tasks do not overlap, but curious how others handle this
Any links or tips to this would be appreciated as we are new to APEX and trying to work these things out up front.
I'm probably not the right person to answer as my Apex team consists of 1 (one) member - me.
However:
We put majority of the business logic (validations, source sql, and process handling) in packages.
Me too, I found that to be the best option. Keep as little code on pages themselves as possible.
As of team development, did you read Managing the Application Life Cycle with Team Development?
Tracking Features might be particularly interesting for you. For example, it contains
Approval status of the feature. Indicates if the feature is to be implemented and the current progress.
which sounds like what you asked for.
I hope that someone - who really works in a team - will see your question and answer; I'd be interested in reading about their experiences and suggestions as well.
When we export application as zip , we can see there is folder structure. So in git we have to follow the same directory structure so it is easy to review and for versioning.
Thanks,
Nagaraju P
I have looked for similar questions, but could find none other than the difference between solutions and projects. Mine is on the same level, I suppose, but is slightly different.
I'm a previous Java developer thrust into C# recently and I am the sole individual charged with setting up source control, project standards, etc. etc. and this is my first go with Visual Studio (using 2010 Pro).
I understand a solution is a "container" for related projects, but I am unsure the best practices of adding projects to a solution which are related, but are of a different type.
For example, would I place a web project in the same solution with a desktop application or mobile app if they are related (rather near identical) in function? They are basically the same app, but in different formats. They may use the same classes (for a contrived example, a Person class).
To me, they seem obviously related, but are different applications, so it would seem they should be in different solutions.
I appreciate any feedback offered.
Thanks in advance.
Those apps should be in one solution, expecialy if they share functionality, common projects etc. Quite good approach is to group projects within a solution using solution folders, for example "Common", "Web", "Mobile", "Setup" etc. This way you can have logical groups inside solution.
I would place them in the same solution, since this makes it easier to have a common class library as one project in that solution.
There are no rules for this so there is no right or wrong answer. It all comes down to how you want to organize your code. We commonly have web apps and console apps in the same solution because they are functionally tied together and share code so the type of project really does not matter.
I would place them in the same solution. You can create different configurations to build each application or build both of them at the same time. This allows you to change the class and verify changes made to the class will work for both applications.
Also if you start to see functionality start to duplicate across applications it is easier to create new classes and project that can apply to both applications.
You can throw everything in one solution. This is convenient if you often have to debug the library and application code together, but if the solution has many projects it can become unwieldy.
One approach is to treat the solution as 'that which will be installed as a unit.' Then your common library will go in one solution, and your mobile and desktop apps in their own solutions. This keeps solutions smaller, but it can be inconvenient when you are developing everything together-- so it works best when the library is very stable.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.
I use Trac to track my bugs related to my php web application. Tough, mainly I register feature request/tasks in trac. Do you find it a good practice, btw?
It's very handy, becouse I can track my tasks via Eclipse/mylyn, comment and fix them. I like trac very much, but I'm afraid of a lot of loosley coupuled tasks, that almost looks like bugs.
Is there a way (or other tracker system) to store my tasks hierarchically? I mean:
Store module (feature)
Add product (feature)
List product (feature)
Delete product (feature)
Unable to delete no name product (Bug)
Other Module.. etc.
Edit: Is there any other good practice where and how to store tasks hierarchically?
Fogbugz has tasks & subtasks, I haven't worked with this feature enough to see if it would help though. You could play around with the hosted eval version, though. (For my taste, the web interface feels to sluggish for me to use it - but I have that problem with lots of things.)
I recognize your problem as one of my own, however I'd prefer to use separate lists/hierarchies.
[update]
At the moment, I am using the starring and heavy search/filtering, and for "keeping my head on" with quickly incoming tasks or larger refactors, I use pen&paper for temporaries (A5 ringbound booklet) and ToDoList for semi-permanents.
JIRA also has this functionality + it's almost free ($10 for 10 users).
See here, and here.
And yes... I think this is good practice, just don't over exploit it.
And this is how it looks like:
You could stick with Trac and look for desired functionality in http://trac-hacks.org/
That looks like what you want (there might be others I just did a fast search):
http://trac-hacks.org/wiki/MasterTicketsPlugin
http://trac-hacks.org/wiki/TracTicketDepgraphPlugin
We are using a couple of plugins from http://trac-hacks.org/ with 0.11 and they work great.
Have a look at the Roundup Issue Tracker.
Years ago, before Trac came out, I wrote several user support and development trackers with it. It's very, very easy to customize the database schema and create new html page templates.
To manage hierarchic tasks, you basically define an IssueClass-based task class that way:
task = IssueClass(db, "task",
dependson=Multilink("task"), # here, you link tasks to other tasks
assignedto=Link("user"),
keyword=Multilink("keyword"),
priority=Link("priority"),
status=Link("status"))
There's a recipe in the Roundup documentation that shows you how to create "blockers" issues, meaning that you can't close an issue if one of its linked issues is not closed:
http://www.roundup-tracker.org/docs/customizing.html#blocking-issues-that-depend-on-other-issues
TargetProcess supports the hierachical structure you want. It's an agile Software Project Management Software, however it features highly customizable development processes and can therefore be used for Waterfall or Kanban/Lean processes also. The deepest hierachical structure you can have goes like this:
Program
Project
Release
Feature
User Story
Task
There is a free community edition which you can use for up to 5 users. TP has a lot more than just task tracking, it features Bug Tracking, Q&A, Help Desk, Time Tracking...
You mind look at GoPlan: http://goplanapp.com/.
It is fully functional project management web application, which provides to create a hierarchy of tasks. There is a free plan, so You can check it easily. You can have task tree with any depth.
Difference between this tool and Trac is that GoPlan is not directed to maintain source code, but a project itself, so You cannot close Your tickets from Eclipse. Unfortunately tasks do not have resolutions (tickets have, but they cannot be arranged in hierarchy), but I think it is not a kind of disadvantage that discourages from using this application.
You've probably already thought of this, but I'll put this in just in case. In Trac, I oftentimes organized tickets as sub-tasks, at least through convention by simply placing links to those tickets in the description of the master ticket. What's nice about this is that closed tickets are shown as crossed out, so you can get an idea of the status of the sub-tickets at a glance. OK, so it's not setting up a hierarchy, but it's a flexible system that also allows you to set up other relationships; for example you can also reference another ticket as a dependency or related issue.
Some of the requirement management tools out there support hierachies, e.g. CaliberRM from Borland. However, these are heavyweight and commercial. This only makes sense if you have some significant amount of information to handle.
I've been investigating OSGi for my company's software, but have recently been recommended to take a look at Impala. According to its web page, Impala is "a dynamic module framework for Java-based web applications, based on the Spring Framework."
At a glance, and looking at this blog post about the differences, the key differences I can see are that Impala is simpler than OSGi, does not manage versioning of third party components, and is far less widely used/known (I do not see a single question about it on Stack Overflow).
I wonder whether people who have direct experience with Impala and OSGi (i.e. those who have investigated it more deeply than reading blog posts and online docs), have any more insights into the practical differences between the two, and/or suggestions about what types of projects each one may be more or less suitable for.
Edit: It may also be interesting to include Springsource Slices into the comparison, although it is as yet an early prototype. At a glance, it appears to only work in DM Server.
Impala's approach to modularity is very weak when it comes to controlled sharing between modules. The problem is that Impala still follows the old J2EE-style hierarchical approach to classloading.
Anybody can write a module system that restricts visibility of classes across modules. The difficult part is how you reintroduce dependencies between modules such that specific classes and interfaces from one module can be seen by another module. In OSGi we do this by exporting and importing packages, so we have a non-hierarchical dependency graph.
In Impala, if you want to see the classes in another module, then your module must be a child or descendant of that module. That is, modules can only see their own classes and those of their ancestors. Now if you want to share some classes with your sibling module (e.g. a library that you both use) then you must move that library up into the classpath of your shared ancestor. In the worst case you have to move it right up to the root module. Now the library is visible to ALL other modules whether they want it or not! Indeed, if another module wanted to use a different version of the library they would be prevented from doing so.
If you simply have a copy of the library in each place where it is used, then you make it impossible for the modules using that library to communicate with each other. They will get ClassCastExceptions when they try to pass objects between each other.
A similar problem is inherent in J2EE if two web applications need to use the same library. Typically J2EE developers just copy the library, but this creates "silo" applications that cannot communicate with each other. It is simply not the way to build modular software.
Steven's points also seem pertinent. As far as I can tell, nobody is using Impala aside from its author.
In my eyes, there is no comparison. OSGi is a mature framework that's been around for 10 years and is the basis for the implementation of most of today's Java containers. OSGi has growing adoption, there are books available and, yes, people talk about it on Stack Overflow!
Impala hasn't even hit a stable release and appears to be a 1-man project, though he is asking for additional developers now.
So, it depends on your criteria. If you are investigating technology out of interest, then I don't see any issue writing stuff with Impala. If you are looking to base your company's future products on it, then I think that would be professionally negligent.