I'll just preface this question by saying I began working with SignalR around 30 hrs ago, so please forgive any amateur questions and feel free to point me to the documentation that I've missed if you know of some. Also, I'm not trying to write a blog post - just explaining the steps I went through to get where I am.
TLDR? skip to the questions at the end...
I need to use the Sql Server Backplane (would love to use Redis but we don't currently deal with Redis and aren't comfortable introducing too many new technologies in one dev cycle). Currently, there isn't a NuGet package available for Microsoft.AspNet.SignalR.SqlServer so I have to work with the Github source.
So I went and pulled down the source, compiled and added the reference to Microsoft.AspNet.SignalR.SqlServer.dll but now compilation fails (specifically when referencing GlobalHost.DependencyResolver.UseSqlServer( ... ) in my code - it's a dependency conflict where the *.SqlServer code is expecting a more recent version of *.SignalR.Core - not really surprising as Github's version has (no doubt) more than a few changes since the NuGet package was released). :(
So the next step is to use the *.Core which I compiled with *.SqlServer. Next problem - the new SignalR version no longer works with *.Hosting.Common or *.Hosting.AspNet which have been replaced with the *.Owin library.
So, I added *.Owin (and Owin - from NuGet) but now I run into yet another problem: the MapHubs( ... ) extension method no longer works - there are extension methods called MapHubs( IAppBuilder builder, ... ) in Owin but they don't work off the RouteTable anymore - they work of Owin.IAppBuilder (hence the need to reference Owin, I suppose).
So this is where I'm at. I did a quick read-up about Owin (seems like a cool concept) but I don't particularly care to spend some hours getting my head around that just to be able to setup SignalR on the server-side. So, now for the questions:
Should I just try to make *.SqlServer play nice with the older NuGet packages of SignalR (in other words, is it likely that changing the dependencies of *.SqlServer will introduce unreliable behaviour)? Or, is there a version of *.SqlServer which works with the current NuGet release version of SignalR available online already?
What specific steps are needed to run SignalR via the Owin host approach (I can't find any examples for this without, say, Nancy integration thrown in - or is that the correct approach)?
What is the replacement approach for the MapHubs method? Where do I get an IAppBuilder from? Am I even supposed to do so?
In a Google Groups post, David Fowler indicates that, with Owin support, the AspNet dependency is no longer required. That's fine - but is there any reason to use SignalR in an ASP.Net MVC app now?
If no part of SignalR is hosted via IIS on the server, does client-side fallback (i.e. SSE or long-polling) go through IIS or does it use the Owin host independently?
Finally, I was planning to run SignalR off an ASP.Net MVC 4 project being hosted as a virtual directory off another existing site - I want to work within a single domain. With the Owin approach is it still feasible to do this when my site is hosted in IIS 7.5?
UPDATE: As per 1. above, I managed to get the code compiling by making *.SqlServer depend upon the current NuGet *.Core implementation. So now I can continue development. I don't think I want to use this in production though - I only had to make a small change relating to disposing an object - but I just don't think it's a good approach. So my questions around the Owin approach still stand - unless someone can convince me that the approach I've taken is fine.
Thanks,
Zac
Short Answer:
Hopefully this will help others out who have this problem (I'm sure there's at least one of you!): it seems that the question I asked was really badly timed as, a couple of hours after posting, SignalR was updated in NuGet to version 1.0.0-rc1. So, to anyone with the same problem I had - just upgrade the package.
Details:
After installing when you look at the references, you'll notice that there's now a Microsoft.AspNet.SignalR.SystemWeb reference. Without having delved into it yet, I'm thinking this is a replacement for *.Hosting.Common and *.Hosting.AspNet because after updating the MapHubs( ... ) extension method works fine.
I also noted that the *.SystemWeb reference depends on *.Owin - so I guess the Owin reference is used as an abstraction layer which allows the SystemWeb hosting to be independent of underlying IIS/other server implementations.
As for the .SqlServer reference, well, that still requires me to compile a version against the NuGet version of *.Core in order to compile locally. I'm going to just work with that for now and hope that the project team release a working version on NuGet sometime in the near-future.
A realistic alternative would be to convince my team that we should throw Redis into the mix - having worked with Redis on other projects, I consider this to be a good option due to performance considerations however it does require Linux which might be a problem for a .Net team...
Related
After Googling, I found a lot of HipHop documentation, but plenty was posted between 2011 and 2013.
Earlier this year was launched a new version of HipHop that even supports Drupal and includes a lot of improvements...
I've always used the Zend Guard to deploy my commercial applications, but now I started to consider seriously the use of HipHop in production, but here comes the question:
We can run an application using only the bytecode HHBC (Without .php source code)?
Follows the reference of my research
https://github.com/facebook/hhvm/wiki/FAQ
The question may seem very obvious, but it is not so easy to find this answer in the project documentation.
Thanks in advance!
Well, yes and no.
HHVM has a so-called RepoAuthoritative mode in which the HHVM will no longer check the existence of the PHP files or how up-to-date they are; instead, it will retrieve the HHBC directly from its cache.
Theoretically, you can follow these steps:
pre-generate the HHBC for all your PHP files and insert that HHBC in HHVM's cache. This is the so-called pre-analysis phase (if you ever see it in HHVM documentation, this is what they mean by it)
turn on RepoAuthoritative mode (it's just 1 line in HHVM's config)
delete your PHP code
This way your PHP applications will run just fine without the source code being present. Doing a server restart won't change this since HHVM's bytecode cache lives on disk (it's implemented as an SQLite database).
However, it will be kind of a headache if you:
want to change something in your code. You would have to copy your code, make the change and repeat the pre-analysis phase.
want to upgrade HHVM to a newer version. HHVM uses its build ID as part of the cache key so, if you upgrade it, the bytecode cache becomes unreachable and, since you'll be running in RepoAuthoritative mode, your application will be reduced to a bunch of HTTP 404 errors. To fix this, you would have to repeat the pre-analysis phase as well.
Bottom line: no upside, big downside. There's just no point in doing it.
PS: I hope I answered your question. It's also possible that I misunderstood what you asked; if that's the case, please let me know in a comment.
We are currently looking at the newest version (2.60) of NopCommerce in MVC and we will be integrating it pretty soon…We’ve downloaded the Source Code and paid the 20$ for the User Guide documentation. The documentation is great! I mean…it is great in the sense that it explains how to deploy, install and how to work around the UI Frontend and Backend. This is great for an overall overview but what it lacks is the understanding of how to work with NopCommerce as a team. What are/is the best practices etc...
As an example (or parallel), if you decide to work with Dotnetnuke as a team, you usually work in the following fashion:
Each developer downloads/installs Dotnetnuke locally on their
machine.
You also download/install Dotnetnuke on a dedicated server (let’s say
dev-server).
As a developer, you work and create modules which you test locally
within your Dotnetnuke installation.
Once it is done, you package your module (and any SQL scripts that
comes with your module) into a zip file.
Once the package is ready, you upload/install that package on the
dedicated server (dev-server).
This approach works great for Dotnetnuke and more importantly if you have a team of developers creating modules.
My question is how does a team work with NopCommerce MVC?
I’m assuming it is a bad idea to directly work within the source code in case your team decides to modify core elements/source which will make any upgrade to newer versions impossible (or break changes).
I’m not sure if my parallel to Dotnetnuke is a correct one…but would anyone have any idea (or help me clarify) how does a team work with NopCommerce MVC.
In addition, should the team only rely on creating plugins for NopCommerce and stay away from modifying the core or should this be irrelevant?
What about adding new objects in SQL (or modifying existing ones) should we prefix our objects in case an eventual NopCommerce MVC upgrade creates similar objects and/or overwrites them?
Thank you for helping me shed some light on this.
Sincerely
Vince
Plugins in NopCommerce are almost like modules in DNN. Depending on what you need to do, it sometimes is necessary to modify the core code.
What I've been doing for the Services is create a new class and inherit from the existing service, then override the function you want to change. Create a new DependencyRegistrar class and set your new service classes as the implementation for that particular interface. Also make sure the Order property is 1 so that your DR class is loaded after the stock one. Since you're inheriting from the core class, any functions you didn't override will be handled by the parent class. If I need to add a new function, I'm just modifying the interface, putting a stub in the stock class, and implementing it in my own.
Views in the Nop.Web project can be overridden by Themes. The Admin stuff and the Web Controllers get trickier. I'm just modifying those files directly.
The Core and Data classes can be done using partial classes to add your new fields.
In any case you will still need to merge changes with your solution when an update is released. My opinion is that you are better off writing clean, readable code now and bite the merge bullet when it comes.
I don't really worry about SQL scripts right now because I'm a single developer but maybe you add a folder for ALTER scripts and name them after the day they were created. Then each dev knows which scripts they need to run when they get latest.
Have been developing with Grails for couple of weeks now,
Though I've loved the experience and the possibilities, I've seen following problems starting up.
Please share if you've had similar issues.. and remedies would help too.
Transaction management (in-built) doesn't seem to work in some circumstances.
AOP with domain objects doesn't work
Grails IDE-plugins are pretty primitive
GWT-Integration (with the plugin)
Plugin installation (fails unusually) probably cause plugins are not matured enough.
Lack of extensive documentation (though what is available is pretty good)
Debugging support
If you actually want solutions for these problems you should post a separate question for each with a lot more information than you've provided here. For example, I can't possibly diagnose the cause of the problem when all I know is
Transaction management (in-built)
doesn't seem to work in some
circumstances.
Here is my opinion on these issues:
Transaction management (in-built) doesn't seem to work in some circumstances.
I haven't noticed any such problem
AOP with domain objects doesn't work
I guess what you mean here is that meta-programming domain objects doesn't work. I have encountered this and haven't found any solution. If you really meant AOP then I can't help you as I've never used it with Groovy.
Grails IDE-plugins are pretty primitive
The IntelliJ plugin is very, very good. The Netbeans plugin is OK. Last time I tried the Eclipse Groovy plugin it was awful. However, I believe that a new Eclipse Groovy plugin has recently been released as part of the Spring Tool Suite (STS). It's supposed to be big improvement on the previous Eclipse Groovy plugin, but I don't think it has much Grails support yet
GWT-Integration (with the plugin)
I don't use GWT, so have no comment
Plugin installation (fails unusually) probably cause plugins are not matured enough.
I've never had problems installing plugins, though if I update a plugin, I sometimes need to manually remove the old version from the .grails directory.
Lack of extensive documentation (though what is available is pretty good)
I think the level of documentation for Grails is way ahead of most OS projects. There is a wide range of Grails books available, there's an active mailing list, and the official document is 176 page long.
Debugging support
Again, it depends on the tools you're using. With IntelliJ, debugging a Grails app is as easy as debugging a Java app with Eclipse.
My own pet peeves about Grails development are:
Upgrading from one version to another is often a very painful process due to lack of backward compatibility. When I upgraded from 1.0.4 to 1.1.1 about 20% of my tests started failing
Application reloading is very hit and miss.
My feedback after few months with Grails:
Didn't happen to me.
I don't use AOP
Wrong. IntelliJ is very good and especially the last beta version. You can download it for a free trial. I know that Eclipse support is very limited and NetBeans becomes better but still behind IntelliJ
I can't say. I don't use it
Agree. My piece of advice here is to follow these following principles: 1.Use plugins as few as you can. Your application will be lighter and more maintainable. Also, you will upgrade Grails version more easily. 2.if you want to use a plugin, test it before with a dummy project. It takes few minutes for creating a grails application and you could test your next plugin rapidly. Be aware that sometimes plugins have compatibility issues between theselves so, do not hesitate to install all of the plugins you need into your dummy project
Agree. Grails is a very complex framework and documentation does not cover every aspect of Grails. But what is available is well explained. Also, grails community is very responsive, so if you don't find something you will easily have an answer in Grails forum or even on StackOverflow
Definitely Agree. Again, with IntelliJ you can debug easily but it is resource-consuming and takes time when reloading your app. So usually, I end up with logging traces and I debugg my full stack of exceptions like that! IMHO, this is one of the major shortcomings of Grails.
I've a portal project built in Rails 1.2.3. I've finished it at end of 2006.
The project are using the following plug-ins:
acts_as_attachment
acts_as_ferret
betternestedset
simple_http_auth
I know all plug-ins (or dependencies) was changed today, or doesn't exists anymore. The DHH says: Don't overestimate the power of versions. But I'm worrying about this.
If I update the rails version, all things will gonna fail. I can change my application to work with new rails version. I think I can read what's now deprecated and change it. But now I need to support all dependencies by myself or change it to other dependencies (Eg: acts_as_attachment to atachment_fu or paperclip). What to say about tomorrow?
My doubt isn't only about Rails, it's about using dependencies to increase productivity. In other projects I've used pure Python code, or even pure Ruby code, or pure Php code. Today I can run it in latest versions of "language/environment" without (or few) changes.
These projects haven't external dependencies, it's just the application code. Maybe using some web framework just as skeleton, but not external projects.
What do you think about this?
When you use someone else's code you pay with your independence for the ready-baked solution for a problem. So it's up to you to decide in each case what's more important to you - build your own stuff and lose time on it now (probably - a lot of time), or use someone else's projects and get the job done right now, but keep tied to them or pay with your time for upgrade/migration later on.
You've said the project worked for you for three years already - and I think it's great, if you need to bring it up to date - it's natural that you have to invest some time to do it, three years is a long timeframe in this area.
It has been a long while since I have really worked with J2EE so please excuse my ignorance. My recent engagement in a Grails project has peaked my interest in Java once more and especially in Grails as it makes building web applications on the Java platform fun again. That being said, I would like an expert to comment on the following requirement that I have for an application built using Grails:
The Design Team (web designers) require access to the GSP pages and edit the view files (layouts, templates, etc.) without bothering the development team (software developers). This scenario can take place both during construction and after deployment into production.
The communication level between the Designers, Developers, and Business Users are not an issue here. However, about 40% of the time, the Business Units involved request changes to the front-end that have no impact on the Developers time but require the time of a Design Team member. Currently, the deployment workflow follows the Grails application through the deployment of a War file to a Tomcat server. I imagine there is a simpler way to allow the Design team to make UI changes without going through the build and deploy lifecycle.
Several of the Design Team members have had exposure to PHP in the past and at times miss the ability to just overwrite a template file to make a UI piece more functional or improve a layout template. I hope there is a similar way to accommodate such simplicity within Grails. I have been told that exploding the War file might be an option but that still requires the reload of the Tomcat hosted application.
If you believe that I looking at the desired solution the wrong way, please do chime in as I am more interested in a workable compromise for all the team members involved. Thank you.
You need to specify the following settings in Config.groovy:
grails.gsp.enable.reload=true
grails.gsp.view.dir="/path/to/gsp/views"
The 'grails.gsp.view.dir' is typically the path to your checked out SVN repo. You can then just 'svn up' everytime you want to update the views.
There is one caveat: When a GSP view is compiled it uses up permgen. Eventually you will run out and need to restart the server.
You could run a server with a version of the application via run-app in development mode. The designers can then make changes to the views and they will reload. They would need to be able to acccess the source code on the server via a share of some kind. As a plus, if you checked out the source the designers could then commit their changes from the server.
The downside is that if the reloading fails or you run out of memory (has been known to happen with lots of reloading) either a developer would need to stop and start the app or you could provide the designers with a script to run to bounce it.
You'd obviously take a performance hit by running in development mode and via run-app but it might a ok trade off in your case.
cheers
Lee
This may not be the direct answer for this question but since you seem to pay attention to designers' role in a project, you may also check my designer friendly GSP implementation which enables designers to view GSP pages even with custom tags thanks to the "tag declaration via attributes" feature.