The company I work for pretty much uses a subsonic DAL for everything we do.
I recently noticed that the domain was released.
So is subsonic dead?
The domain does seem dead. Their github repository is still online though, with most recent activity from a month ago. The author Rob has a blog but he doesn't seem to have addressed his poor domain, though he does seem to acknowledge that it hasn't seen much attention from him.
For all your info, the domain is back up (probably got lost in the flood of Rob's inbox).
I put a lot of time in Jan-Feb 2012 into fixing up all the outstanding bugs in SubSonic 2, including patching, fixing or removing a lot of the failing unit tests (there were quite a few), actioning outstanding pull requests, and generally giving it a good tune up.
I had also added an MS Access provider and an auto enum generator to it.
But SS2 is very much 'mature' now, and I can't see much happening to it apart from bug fixes. That said, now that the help resources are back up, it's still a great and complete package. If there's not much active patching, that may be because it doesn't need any.
SS3 takes the project in a very different direction. I'm happy using it, but as with all these things, I mainly concentrate on what I can do WITH it rather than the tool itself. There is a pretty big backlog of outstanding stuff on SS3, and I'm not up with or even that keen on LINQ, so not sure how I'd go trying to fix anything to do with that.
And Rob has moved on to Massive, his .NET 4 dynamic tool.
UPDATE: The actual official SubSonic site is at: subsonic.wekeroad.com
Subsonicproject.com is a secondary site previously registered by contributor Eric Kemp, fallen to domain sqatters, largely broken. I nearly fell over when Rob told me this.
YES!
Rest in peace, my old friend :(
Related
Some years ago Apple released the iCloud sync of Core Data apps. Then I released an app for iPad / iPhone / MAC with a shared model using the new Apple mechanism.
Things have not gone as expected. The sync mechanism sometimes doesn't work. For example, the last months, in my case, rarely the sync ends well through my 3 devices. Uploading objects in general works fine. But the download process of new or deleted objects normaly crash.
Apple released some time ago a way to force the devices to redownload ALL the objects of the model (NSPersistentStoreRebuildFromUbiquitousContentOption) that normaly works but it's not an acceptable solution.
My questions: Does someone have accomplished to get iCloud + Core Data working fine? What about running iCloud+CD under iOS 9 + El capitan, any experience?
I'm evaluating migrate to new CloudKIT API but I don't like the idea of self-manage an object upload if the device is offline. Does the new mechanism of push notifications indicating model changes works fine?
Thanks
This is a question I've researched deeply in these last few months, I'm afraid without a definitive answer.
Here's what I can tell you from my experience:
If you, like me, don't want to start over with CloudKit, which works reliably but requires you to manually handle much of the syncing work and the conversion of CKRecords to ManagedObjects, give Ensembles.io a chance: it's working very well for me, the layer between Core Data and iCloud really is working in my case, where CD+iCloud didn't.
I'm using the 1.0 version, which is open source and supports iCloud as one of its possible backends (and version 2.0, paid, supports even more); in a few days I got reliable sync with automatic de-duplication (you have to provide a uniqueIdentifier property to have it working, but I already had something in place...).
The only issue I haven't figured out yet: sometimes (1 case out of 10, I'd say) an object doesn't sync right away when edited or deleted, but it always get on the other device when another object is added, edited or deleted: nothing got lost and everything has been handled "automatically" for me when these delays occurred, but still, I'd prefer that everything always synced right away.
Ensembles also has a good logging for debug, something you'll appreciate coming from vanilla CD+iCloud.
If you want to give it a try, you should take a look at these resources:
Ensembles.io company website
Ensembles on Github
A presentation/introduction from the creator of Ensembles
This, and other posts, on a blog I found after I implemented Ensembles in my Swift project; I could have used these informations, if I had found them before... but they're more useful if you're writing Swift code, if you're Objective C then the official Ensembles book is the way to go
If you are absolutely sure that you don't want layers / third party code between Core Data and iCloud (I thought so myself, but I've changed my mind when I realized I lost three months of my life and got nothing in return), the implementations of Core Data + iCloud that I've found online and looked more promising were these:
Sample Library Style Core Data Apps with iCloud Integration, looks a bit complex to me, but I've read many good things
Tim Roadley's book and sample code
I haven't tried myself these last two solutions, because my last plan of attack was to try Ensembles and, if it didn't work for me, go with those approaches. Since Ensembles has been very good to me, I didn't need to try them, but again they looked solid.
One last thought that bothers me: in 2015 WWDC sessions there's no mention of Core Data + iCloud. This, to me, spells doom for the syncing solution we're choosing.
Hope this helps.
We are looking to implement an open source identity management system and have identified ForgeRock's stack as the best technology to implement.
The high cost of ForgeRock support and its per-User pricing model, however, is a potential roadblock. Our current User base is ~45K, but we expect to ramp up to 1M in the next 2 years.
So we're looking into scenarios where we proceed without FR Support. The lack of FR Maintenance releases would seem to put a damper on that, so we're curious if others have gone that route.
What has been your experience?
What kind of projects have you done this for? Size, etc.
In the absence of FR's Maintenance releases, have you been able to easily create your own patches?
What are some potential pitfalls?
If there are blogs or other communities that deal with this topic, please point me in their general direction.
Thanks.
As a community user I did use OpenAM(/OpenSSO) and OpenDJ for the past 6 years or so, but it was a very small deployment (10k users only 1 server instance from both products).
1) In the early stages we did have reliability issues with OpenAM, which we mostly resolved by restarting the server instances - clearly wasn't preferred, but we didn't really spend too much development effort on actually trying to resolve it (plus lacked the necessary knowledge for investigation back then). After spending some actual effort on trying to learn the product it turned out that the most of our issues were either self-inflicted (badly written customizations, or misconfigurations), or was actually something that got recently resolved in the OpenAM project and was relatively simple to backport to our version.
Of course the experience itself largely depends on how often you want to make configuration changes in the deployment though, since we weren't changing a lot of things over the years, OpenAM just worked nicely for long intervals without requiring any kind of maintenance.
3) Since we didn't really ran into new issues (the config barely changed), there weren't too many surprises after a while. The security patches were mostly simple to backport and didn't cause too much trouble (It did help that after 1,5 years I became a FR employee and I actively worked on OpenAM issues though :) )
4) I think running without subscription has its risks, but they mostly relate to:
are you planning to roll out new features based on OpenAM functionality during that 2 years (i.e. are you planning to constantly make changes to the deployment)?
do you have good developers to work on these features? Working with OpenAM for example can quite easily require you to have a look at the source code to figure out how things work, the quality of the documentation has improved a lot over the years though. Regardless, backporting fixes are going to be more and more difficult over time, as the releases will differ a lot more (since the development team is getting bigger and bigger for each projects) - and even then you can't just assume that all the issues you run into are by definition already resolved in trunk. The need to resolve some of the issues on your own is a cost/risk you need to take into account.
what kind of SLA do you want to have for your deployment? Is your business going bankrupt after a 1 minute outage? Is it acceptable to just frequently restart your service (in case you run into some weird issues)?
do you really need support for all 3 products? For example my background would allow me to work easily without OpenAM support, but I would be in the deep end if something is going wrong with my provisioning system...
And a generic remark:
Having user growth of 20x within two years sounds a bit unrealistic, or very hopeful at least. Maybe what you should look for is a 1 year subscription for a bit more reasonable target number and then have a renewal once you have a better understanding of customer growth in your business?
(as at 1st June 2012)
A very simple question I would really appreciate input from others (I think we all could) who are either wondering the same or have decided to go with it (if so, any user experiences shared would be great).
I have 2 main issues which seem common on stackoverflow and on various blogs, so I know I'm not the only person experiencing them.
Occasionally my sync gets corrupted for one reason or another and the sync either fails on certain data or fails to sync altogether.
Pre populating data is essential for my app, there's no reliable way of doing this (without asking the user - which isn't reliable)
I've seen many good work arounds to both these issues but I can't help feeling that my users will encounter problems still.
I'd be really interested to learn of any experiences particularly from those that have decided to publish using iCloud and Core-Data.
iCloud has been around a while now but even on iOS 5.1.1 it doesn't seem stable enough, surely a more reliable version can't be too far away.
It is hard to answer this one without "Making statements based on opinion", but it's one worth giving partially backed up opinions on to hopefully save others some time and frustration.
My opinion is that it's just not ready. I unfortunately have an app in the wild at the moment based around CoreData + iCloud and even though we danced around a number of iCloud bugs to finally get it stable enough to pass reasonably thorough testing some users are still running into the corrupted sync states. I've spent a healthy portion of my recent life trying to make it work and am currently reluctantly reimplementing the app without Core Data. I really hope that it stabilizes soon as I genuinely like most of it.
I have a small software project with a couple clients. What I'm looking for something with the following abilities:
clients can submit feature requests, bugs, or tasks
clients can see the status of open and closed issues
clients can see a change log
a place for me to post updates or news
Nice to haves:
clients can only see the issues that
they've posted; not other clients'
a hosted solution
So far, the choices seem overwhelming. I've looked at Mantis and Hiveminder. Unfuddle seems pretty close. I've avoided FogBugz for the price (and it seems like overkill) and Trac as I'm trying to avoid hosting something myself. Most of the existing solutions seem to be geared towards a team of developers and not for developer-client relations. Anyone have any recommendations?
I know that you said you'd rejected FogBugz -- but your description makes it sound like this might be a solo development effort. Have you considered the free Student and Startup Edition of Fogbugz?
I ended up going with Mantis. Its per project permissions actually works out pretty well for multiple exclusive clients.
Take a look at uservoice.com and getsatisfaction.com - probably what you need. It's not positioned as bug-tracking, so you won't have complex workflows or permission schemes, I guess, but maybe that's right for a small team.
Igor
In my organisation, we have some very inefficient processes around managing requirements, tracking what was actually delivered on what versions, etc, do subsequent releases break previous functionality, etc - its currently all managed manually. The requirements are spread over several documents and issue trackers, and the implementation details is in code in subversion, Jira, TestLink. I'm trying to put together a system that consolidates the requirements info, so that it is sourced from a single, authoritative source, is accessible via standard interfaces - web services, browsers, etc, and can be automatically validated against. The actual domain knowledge is not that complicated but is highly proprietary and non-standard (i.e., not just customers with addresses, emails, etc), and is relational: customers have certain functionalities, features switched on/off, specific datasources hooked up - all on specific versions. So modelling this should be straightforward.
Can anyone advise the best approach for this - I a certain that I can develop a system from scratch that matches exactly the requirements, in say ruby on rails, grails, or some RAD framework. But I'm having difficulty getting management buy-in, they would feel safer with an off the shelf solution.
Can anyone recommend such a system? Or am I better off building it from scratch, as I feel I am? I'm afraid a bought system would take just as long to deploy, and would not meet our requirements.
Thanks for any advice.
I believe that you are describing two different problems. The first is getting everyone to standardize and the second is selecting a good tool for requirements management. I wouldn't worry so much about the tool as I would the process and the people. Having the best tool in the world won't help if your various project managers don't want to share.
So, my suggestion is to start simple. Grab Redmine or Trac and take on the challenge of getting everyone to standardize. Once you have everyone in the right mindset then you can improve the tools you use for storage.
{disclaimer - mentioning my employer's product}
The brief experiments I made with a commercial tool RequisitePro seemed pretty good me. Allowed one to annotate existing Word docs and create a real-time linked database of the identified requisistes then perform lots of analysis and tracking of them.
Sometimes when I see a commercial product I think "Oh, well nice glossy bits but the fundamentals I could knock up in Perl in a weekend." That's not the case with this stuff. I would certainly look at commercial products in this space and exeperiment with a couple (ReqPro has a free trial, I guess the competition will too) before spending time on my own development.
Thanks a mill for the reply. I will take a look at RequisitePro, at least I'll be following the "Nobody ever got fired for buying IBM" strategy ;) youre right, and I kinda knew it, in these situations, buy is better. It is tempting when I can visualise throwing it together quickly, but theres other tradeoffs and risks with that approach.
Thanks,
Justin
While Requisite Pro enforces a standard and that can certainly help you in your task, I'd certainly second Mark on trying to standardize the input by agreement with personnel and using a more flexible tool like Trac, Redmine (which both have incredibly fast deploy and setup times, especially if you host them from a VM) or even a custom one if you can get the management to endorse your project.