We use the C-Bindings of the Apache Geode Native client (state at #44abff89f65f) in one of our products. Unfortunately, we have discovered that the bindings have recently been deleted from the project.
https://issues.apache.org/jira/browse/GEODE-10058
Looking for the reason oft the removal we’ve only found a comment stating that „the c-bindings layer itself are now defunct, as they are being replaced by a pure C# client“. Since we are using the C-bindings in a pure C application, we are now wondering how to proceed. Actually, we were hoping that the C-bindings would be extended even further in future.
Does someone know if the development of the C-Bindings has really stopped or if they are going to be part of a standalone software/Git project?
Thanks!
Related
We want to use surrealdb as our database but how would we use it in Phoenix? What configurations are needed? If you have any Experiences with this pls feel free to share :)
I am working on SurrealDB library for Elixir. You can see how install and configure it on github: https://github.com/ricardombiot/surreal_ex
If you wants works with phoenix, you can create a project without ecto (using --no-ecto flags) and after includes library dependence and start your project!
For big projects/big-teams, I would recommend creates an umbrella project where you have your application will be divide on independent modules (E.g. A project for Web, other for REST, other for each service as users, mailing, booking.. so on…). The modular architecture improves testeability, reusability, extensibility of each part of your application.
Note: I had working on Library only one week (Nov 26, 2022) then consider that maybe some things can change on next versions.
I'm learning REPL for Java 9 and how to utilize it effectively. Considering Java is heavy on the configuration and external dependencies this has made experiments for anything outside the trivial more work to configure than just waiting for a build/run. For instance, to evaluate something more than a trivial line of Java, based on just its runtime, one has to reference an external library as well as its own dependencies. This over-complicates things and perhaps make the point of such a feature moot for real-world scenarios.
Until IDE's integrate REPL and automatically manage/inject dependent libraries, how does one use the feature without the feature becoming more of a burden then the hurdle it was meant to overcome? Please note I'm not looking for conjecture, but methods in which one has worked to accomplish this.
I'm using the Kulla repo here to experiment.
As of October 2015 REPL (project Kulla) is still is not integrated, and Modular JDK, runtime images goes as second alternative download. Once they are all integrated in Dec 2015, there should start work and testing of them together.
As of October 2015 all tutorials suggest starting from building sources:
JDK 9 REPL: Getting Started (Tech Tip #87)
REPL_Tutorial.pdf
JShell and REPL in Java 9
Java9-New-HTTP-2-and-REPL
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
I'm working on legacy code in a DotNetNuke module, trying to get classes and behaviors under a testing framework: I'm taking this opportunity to follow advice from the "Working effectively with legacy code" book, so what happens is that i'm trying to define areas which can be tested thoroughly and then converted to services. Then i'd like to use an IoC framework for it to work. For now, i've set eyes on Ninject.
However i'm hitting a design problem: as i'm in a DotNetNuke module, i can't really change application-wide structure: for example i can't derive the Application from NinjectHttpApplication. I can't use these suggestions from SO either.
I was thinking about having the Kernel in a static class that my module would set up and then use but from what i've read around it's a very bad idea.
So i'm starting to ask myself if it's possible to use an IoC in an application that hasn't been set up to support it from scratch. If i'm supposed to have a whole dependency tree loaded for each request, how can i rewrite legacy code locally and benefit from IoC? Is there a pattern where IoC use can grow out from very local rewrites?
Even though i'm working with DotNetNuke, any standalone component that can be installed into an independent framework begs the same question. Also i'm not targeting Ninject specifically, if another IoC framework can help in this case i'm willing to consider it.
From my experience, your best bet to get this type of abstraction within the context of DotNetNuke is by using the WebFormsMVP framework. This is really the only sane way I've found to do unit testing in a DNN module, and if memory serves I spent awhile trying to wire up Ninject a year or so ago.
But be warned, it is still WebForms and will never be drop dead simple. And without knowing your existing code base, I'd have a hard time knowing how easy it will be to make the migration.
I have a couple of resources on GitHub that you can check out for reference:
The first is a module template that should act as a solid starting point:
https://github.com/irobinson/WebFormsMvp-DNN-Module-Template
The second is a small example project:
https://github.com/irobinson/BeerCollectionMVP
Depending on the version of DNN you're using, it may or may not already ship with WebFormsMVP, but you should be able to either bundle the dependencies w/ your module or upgrade to the newer version of DNN if that's reasonable.
i want to port my application to CodeIgniter but i am wondering whether i should use their v2.0 or v1.72 (then when they release 2.0, upgrade it).
i have never used a framework before so i don't exactly know what implies when upgrading a framework: what does it mean practically - i just move the folders and it will work? or do i have to change a lot of settings, file structure etc? could someone enlighten me about the upgrade process.
and what would you use: v.1.72 or v2.0?
if i'm using the latest version, is there a good documentation for it somewhere so you can read about how to use the new features: packages, drivers and so on.
thanks
You can read about some of the changes in 2.0 here.
I would image the upgrade process should be straightforward as long as you do not use any features that are different/removed such as plugins. Just take your models, controllers, etc and drop them into the 2.0 framework. Then regression test you whole app, fixing any problems as you see them...
If you are selling this app or making something mission critical then of course v1.7.2 is the best choice. That said I have PyroCMS running on v2.0 and since some of my bug-fixes were merged it seems stable enough.
One should consider time frames for deployment:
If it is one week, then stick to v1.7.2
If it is three months, go with v2
Assuming three months is approximately to time for a release to stabilise?