As you can see here, while a Sentry project has a setting for platform, it has instructions (sections to the left) for connecting any platform to its logging:
Furthermore it works when logging from multiple programming languages, and it's not obvious in the stream, which errors are from which programming languages until you go to the individual error.
Is the platform setting just marking a project as one language, so you may have one project for Python, one project for JS, etc. or are there more important ramifications of changing the "platform" of a project? I saw in the changelog that "Sentry will now ask for your project’s platform." since 5.2 although it isn't clear what this option is for, as it will apparently log from any language's Raven logger.
This is the best answer I've found (and it's still pretty vague):
This is mostly so we can apply some sane defaults on how to render the stack frames visually.
We definitely don't prevent you from sending a JavaScript error to a project that is set to Python, for example.
Related
When building YouCompleteMe, there is an option to USE_CLANG_TIDY, which seems to be off by default (at least when building on Linux). What is the benefit to turning it on?
I got curious after seeing --clang-tidy flag in installer options as well. Here is what I found going through YCM's git history:
This is the commit where this feature was merged to YouCompleteMe from ycmd (YCM's backend).
This is the corresponding pull request and discussion in ycmd. One of developers says:
i feel like we should only be running clang-tidy when developing, not when building for users.
So, this feature isn't intended for users of the plugin, but rather for developers of the plugin.
TL;DR: There is no benefit to turning it on from end-user perspective.
I recently started exploring npm and installed a github repo yoonic/nicistore.
But when I try to build it fails.
My question is if I start building things on top of node, which I see has tooo many dependencies from different vendors, Am I completely on the mercy of the respective package developers?
I have seen that most node based github repos fail to build in the first try. If I update one of the modules by running a console command, Is it likely to break all the application?
And if It is does, doesn't it prove node.js an unreliable and unstable development platform?
Think of it as the opposite of most other languages.
You are writing an app in Java.
You want to use LibA, LibB and LibC.
So you try to use LibC 2.4, and as soon as you do, your manager throws all kinds of errors at you.
Why?
Because LibB is using LibC 1.9
So now what are your options?
Strip out all of the calls to all of the new API for LibC that you wanted to use...
...or hope that LibB is open-source, and you can contribute an update for a new version of it, so that you can use the latest version of LibC (and hope it doesn't update).
So now you've done that... but now you've broken your LibA, because it wants the old LibB.
You didn't even want LibA, you just had to have it for your app to be happy with your framework, and the libs that you did actually want to use (B and C). LibA is closed-source, and isn't maintained, anymore. Tough luck. Go back to your old ways, and forget about how much better life could be, if you could only use your framework with the new version of LibC. Or start praying that your framework does a major rewrite, to get rid of the LibA dependency... but then figure out what new hell you have to deal with, just to get LibC working.
Is this really better than Node?
What node allows you to do is install dependencies which are at different versions than the same library that your dependencies are using.
Not that you can't do that with Java, too... but the entire community has decided that it's just not ever going to try to do that, and thus outlaw it at a tool level.
Next, you see too many things which leave you at the mercy of too many vendors...
Going back to Java (or C++, or nearly any mainstream language), looking at Java, itself, how many libraries are made by Sun Microsystems, or by James Gosling?
Moreover, if you want to boil it down, to suggest using only, say, one huge, overarching framework (like Spring MVC) and using no other libraries of any kind (like JodaTime), then how many libraries does Spring itself lean on, and why are they of no concern to you, even if you're just using the compiled VM bytecode?
In fact, a strong argument could be made to be more wary of compiled binaries, in languages where it was traditional to see strong, copy-left licensing like that of the GNU GPL... in that realm, you open yourself up to craziness.
Most of the Node stuff, by comparison, is dirt-simple freeware. And even if it's not, it's quickly replaceable as most are micro-libraries.
I would suggest that updating a Node package your server depends on, via CLI is less hazardous than doing the same to a full-fledged Java project, if your goal is to see your project compile again, some time in the next week, but with the newer fixes/features...
...but if you're talking about a full-scale, production application, you also want to be cognizant of what it is you're doing, with regards to your codebase, regardless.
As to why things don't build for you on the first try, assuming that you're on a non-Windows platform, and your environment is up to date, I don't know.
Most C/C++ projects I clone don't build for me, first try, either. I usually forget something, or there was something poorly documented, or the actual project was set up to make unfair assumptions about the system it would operate in.
Does that mean that C++ is an unreliable/unstable development platform?
Or the hours/days spent on getting Eclipse set up in an enterprise environment, with all kinds of crazy, company-specific projects and project settings?
It sounds like a case of bad design, more than anything.
Then again, most of my projects these days are wrapped in Docker containers. They all run in the same environment, whether they're running in Windows, on a Mac, or on the server. That tends to take the sting out of building projects, regardless of what language the code is in, or what VM / processor they're running on.
You should also be using NPM shrinkwrap files, or Yarn Lockfiles to preserve the build configuration, with the known-working versions of libraries. And you should have unit and integration tests to ensure that changing library versions has no discernible impact on your system.
When developing front-end code for the browser, I often use the es2017 preset when transpiling down to a distribution bundle, which allows me all the conveniences of the included transformers. For conventional modules, I usually stick to whatever the required node engine I've specified for that particular module supports.
I would like to start developing these "conventional" modules using babel transformers as well, but I can foresee drawbacks to this, including:
It might inhibit the debugging workflow (more specifically when working with an IDE)
The performance of the module might suffer
What's the current state on this matter - would you say it makes sense to use babel in conventional modules given the aforementioned and other trade-offs? What are the pros/cons for your preferred workflow?
Bonus question: What are some reputable modules and/or module authors out there that are already using this technique? I've seen Facebook do it for their react ecosystem but I guess that makes sense since those are mostly modules for the browser.
It is converted back to vanilla JS (babel does that part).
What you get is that you can utilize Classes which I found useful.
Hopefully with time, browsers will support ES6 and we will not need babel.
The only drawback is that when debugging, you have to produce a source map, but that is temporary, see above.
To answer your second question: I'm using React in one of the websites, and most of the modules I needed (from npm) are using ES6.
I believe that the trade-offs or drawbacks that you mention both do not apply to developing nodejs code using babel as ES7 transpiler. Personally, I find using ES7 features with node tremendously productive.
There is source map support for debugging. I use karma for testing and it comes with excellent source map support (I use IntelliJ but I believe most IDEs will do). You can checkout this REST-API repository on github. It's a nice stack for building nodejs data backend. It uses karma for testing - even comes with code coverage support. It also integrates with pm2 for scaling and availability.
Regarding performance: I think transpiled code has been shown to run faster in many scenarios than the code a developer would write when not having advanced language features available. I will post some links later.
I have created a C++ application using Pjsip Stack and my next step to create a plug-in,for which i am using firebreath. Being a newbee, I dont have any idea of including my C++ project in Firebreath application. Although I searched many links for over a week and tried stuff on my own, I couldnt come up with solution to my problem.
If I can get any guidance for the same I'll be grateful.
The first step is to learn how to write a firebreath plugin, which you can do by going to http://firebreath.org and following the tutorials. You need to keep a few things in mind, though:
Plugins have a different lifecycle than applications.
They start when the browser says and have to go away when the browser says and they can't block the main thread.
They run in a process that they don't own.
Global variables are shared between all instances of the plugin
There could be any number of said instances
Things like the current working directory should probably be left alone.
Turning an application into a plugin is more a process of porting than it is of embedding, and how hard it is depends on how well the application is written; remember that your plugin could be instantiated and destroyed many times before the process is unloaded, so if you have memory leaks it can be a major problem.
The main thing, though, as I said earlier, is just to learn how to write a firebreath plugin. You can best start that by looking at the examples in the repo (particularly fbtestplugin) and following the tutorial to create a new project, then just play until you figure it out. There is an IRC chat room and a google group where you can get help.
I had a fresh look at Haxe again recently and realized that I had overlooked some of its elegance before. But I guess it lacks some visibility among the developers still.
So my question is, does anybody here use it for production? If so, how do you use it? What are the gotchas or difficulties you encounter? Do you recommend it for future projects?
I use Haxe to develop all my Flash applications, and I love it. I develop on Linux and with Emacs,
and I really like how I can make Haxe fit within my preferred development environment. I just use
simple Makefiles that look something like:
project.swf: Project.hx
haxe project.hxml
It's really easy to get started in Haxe, and it's very elegant. I've
had no problems at all using Haxe as compared to using the Adobe Flash
builders, and have developed a bunch of big projects including PanningPedagogy, The Orchive,Cantillion and Audioscapes.
I've released the source code to all of these as GPL on SourceForge, check them out at:
https://sourceforge.net/projects/panning/
https://sourceforge.net/projects/orcaannotator/
https://sourceforge.net/projects/cantillion/
https://sourceforge.net/projects/margridflash/
You might find some useful information in the lists of Projects Using Haxe and People Using Haxe.
My company uses Haxe for production use. For programming swf content is absolutly no problem on the technical side. Using it on the server side is a little bit harder. If you Haxe for PHP you sometimes have some problems with typing (this is more or less a PHP problem). The neko vm is very stable and very very fast but it takes some time to get it running with all you other server software (mysql, apache - mod_rewrite), but once you got it you it is very stable.
We used it for generation swf applications, tried the possibilies of Haxe JS. Also we created socket server for a multiplayer game and start to generate all our webpages with Haxe PHP or neko.
The community is very helpful, the documentation is sometimes a little bit to short.
This is only my opinion and the experiences I made.
For those of us who don't know what Haxe is, it's a programming language for developing web apps. It has multiple compiler targets (Flash, php, JavaScript, and the Neko language's VM)
Welcome to haxe [haxe.org]
Haxe entry on Wikipedia
Haxe are currently gaining more popularity as a cross-platform development (mainly for game development) tools thanks to NME/OpenFL: http://www.openfl.org/
Write once in Haxe and deploy it to Flash, Android, iOS, and more..
HaxeJS is very good for web production, it allows to use all the underlying js modules while giving extra abilities like pre-processor, typed fields, conditional-compilation, classes, haxe libraries, refactoring and auto-completion from IDE etc.. plus its very quick to compile and output ready-to-use js files.
I haven't tried microsoft typescript, but so far I've been using HaxeJS for both client and server (nodejs) on a few production projects and it feels a great choice. The only issue is if i want to share js libraries or npm modules with others, I'll probably need to rewrite the js by hand then.
We used it at a previous internship, for an internal web system. We only compiled to js and I just once compiled some minor code to both js and C#. I can say it worked quite well and many custom widgets were made at the time. Debugging the produced js wasn't that bad either, but it sometimes didn't produce the code you wanted it to (I remember one string comparison issue in js, where the reference was being compared instead of the value). The code was deployed in production and had worked fine for years. I'm pretty sure they still use it today.
That was in 2013, I haven't used it since. One problem I did have was trying to compile code made in version 2.08 using version 2.10. It needed some minor, but non-obvious adjustments. I can't quite comment on more recent releases, but I'd be a bit careful on not breaking large pieces of code by upgrading to new versions of the compiler.
You compile, haxelib run flow run "target" in target you type for example web, and thats all, in your bin, folder you get your files, remember to configure your project.flow file acording to your target and project.