GitHub has a feature where it can show you which languages your projects use with a percentage.
However, due to large JS packages it is mostly showing as JavaScript.
Is there a way I can I can see the code composition for my projects individually, even if it's not on GitHub? I'm trying to use it for my portfolio.
Related
I looked through Github search docs for repos and code and I am not sure if it is possible.
I want to find popular open source projects that use a specific library to see how they handle particular design patterns. In my case, I am looking for popular Android projects that use Dagger 2.
I tried using a code search for com.google.dagger:dagger-android-processor: in .gradle which gives me 14k+ results for mostly unpopular projects. I would basically just want to sort by forks/stars, which is not an option as far as I can see.
If this is not possible with Github's search I am happy with any alternative.
For projects that use one of the package managers which is supported by GitHub (RubyGemsm, NPM, PyPI, Maven, Nuget), you can use ghtopdep
Related issue
A Code search would not allow sorting through repository stars (as stated here)
Maybe:
using a BigQuery would allow using that criteria (like this one)
or using GraphQL
Is it possible to embed code coverage results (stored in SonarQube) into Github projects as one of those embeddable icon gadgets (not sure what their name is; it would be great if somebody to tell me that as well)...? I'm referring to the ones that show the build status, for example.
The only thing currently available is this under-development plugin, which was first discussed in this Google Group thread. Note that this project appears to be in its infancy.
EDIT
This plugin has since been released, and can be installed directly from the Update Center
EDIT 2
With SonarQube 7.1, badges become a native feature.
Using a plugin in no longer needed, as some new APIs are now added that will do what you want. You can use this snippet in your .md files:
[](https://{domain}/component_measures/metric/coverage/list?id={projectName})
Note that you have to replace parameters inside {}s with your own values. If you are using on-premise version, the domain will be your own domain and if you are using cloud version, it will be sonarcloud.io.
Also note that this will work only for public projects. For private ones, I could not find any solution.
And finally as a side note, the metric parameter takes some values other than coverage and gives other fantastic badges that you may find helpful:
bugs, code_smells, coverage, duplicated_lines_density, ncloc, sqale_rating, alert_status, reliability_rating, security_rating, sqale_index, vulnerabilities
Situation:
I need several swf/exe output files compiled in FlashDevelop from several projects. More than 60% of ActionScript 3.0 source is common for all project, rest are project-specific. How can I organize that in FlashDevelop? I want to have "one-click-to-build all" setting without duplicating common codebase (so when I need to fix something I do not need to copy-paste solution into several files).
All sources are under develeopment and will change very often.
A straightforward solution is to make an external classpath, for instance:
c:\dev\shared_src\
c:\dev\project1\
c:\dev\project2\
Then configure each project:
Project Properties > Classpath
Add Classpath > select '../shared_src'
PS: of course you should keep everything under source control.
Using svn:externals you could structure your repository in such a way that the commom parts are stored just once in the source control system, so changes made can be synchronised with just a single commit and update cycle.
For example, imagine that you have ^/ProjectA and ^/ProjectB, each of with require ^/Common as a sub directory.
Using svn:externals, pull ^/Common into both projects.
The exact nature of doing this will depend on the version of svn you use, and any client you use (such as TortoiseSvn). Refer to the relevant edition of the svn book for specifics.
The ease of implementing this will depend quite a lot on how separate the common code currently is in your application; and pulling in directories as directories is much more practical than trying to pull them into an existing directory; and unfortunately wildcards for filepaths are not supported.
However, based on your description of your aim; this is the most straight-forward solution I can imagine.
Hope this helps.
I see a lot of questions, both here on SO and elsewhere, about "maintaining
common libraries in a VCS". That is, projects foo and bar both depend on
libbaz, and the questioner is wondering how they should import the source
for libbaz into the VCS for each project.
My question is: WTF? If libbaz is a library, then foo doesn't need its
source code at all. There are some libraries that are reasonably designed
to be used in this manner (eg gnulib), but for the most part foo and bar
ought to just link against the library.
I guess my thinking is: if you cut-and-paste source for a library into
your own source tree, then you obviously don't care about future updates
to the library. If you care about updates, then just link against the
library and trust the library maintainers to maintain a stable API.
If you don't trust the API to remain stable, then you can't blindly
update your own copy of the source anyway, so what is gained?
To summarize the question: why would anyone want to maintain a copy of a
library in the source code for a project rather than just linking against
that library and requiring it as a dependency?
If the only answer is "don't want the dependency", then why not just
distribute a copy of the library along with your app, but keep them
totally separate?
The use of vendor branches to control 3rd party dependencies is discussed in some depth in the Subversion book. As I understand it, the basic advantages are guaranteeing a stable API and uniformity of libraries for all developers, and the ability to control custom modifications in house in the same versioning system.
On the project I'm working on right now, we've got the main code (which is in one Subversion project) and a host of assorted libraries from various places that are in their own Subversion modules. The Visual Studio solution maintains separate projects for each of them and links them together at the end. If we were working on Unix or similar OSs, we'd do the same thing.
The only downside I see is that I sometimes forget to update one of the libraries that changes more frequently, and my code doesn't compile until I notice that. If we had the libraries in the same module, then we wouldn't have that problem. (Not that I'd ever do it that way. The gains in flexibility and the ability to use different libraries with different main projects are just too great.)
The API is a red herring here: either it stays the same or it changes, and if it changed we'd have to update the main code either way. So is the question of source vs. binary libraries (either we compile them with the main project, or we don't).
I'm developing a mobile phone application that targets a lot of mobile devices based on the capabilities they offer. There would be a base feature set which all phones are expected to support and then there would be additional features that would depend on specific set of phones.
How do I manage such a code base in terms of a version control system?
I have experience with CVS and VSS but both don't quite fit into my needs for this kind of an application. The last thing I would want to do is branch the code for each of these device sets.
Let me make this a bit more clear with the help of an example. Lets say I'm developing a J2ME application using MIDP 2.0. This is the base feature set that I would expect all phones supporting MIDP 2.0 to have. On top of this I would extend this application for specific sets of phones using their SDK's. For eg. Nokia S40, Nokia S60, Sony Ericsson, Blackberry etc. All these provide additional functionalities which lets you build more on top of your base application and most of the times these would affect your whole code base from UI to core logic.
One way to achieve this is to use a combination of a build system with preprocessor flags and trying to separate the differences enough to not have too many dependencies. This can get quite complicated at times. I am wondering if there is an easier way to handle this using a smart source control system....
I would look at Subversion's svn:externals.
With svn 1.5 you can use relative references for directories, and svn 1.6 supports file-based externals.
For example a structure like,
/Phone1/Base
/Phone1/Feature1
/Phone1/Feature2
/Phone2/Base
/Phone2/Feature1
/Phone2/Feature3
Would be easily acheived using svn:externals.
In Subversion, your repository structure is very flexible, here is one way (of many) you could lay that out:
trunk/Features/Base
trunk/Features/Feature1
trunk/Features/Feature2
trunk/Features/Feature2
trunk/Phones/Phone1 (with svn:externals to Base, Feature1, ...)
trunk/Phones/Phone2 (with svn:externals to Base, Feature3, ...)
One hint though: Make sure that you use a specific Subversion revision for each external reference, it may not seem important when starting out, but 6 months down the track it will :)
I like Subversion for projects which don't have a lot of developers on it. From your problem statement, to me it sounds like you should be able to acheive what you want with a good build system. So I don't think the source control itself would make much a difference. But I may be misunderstanding your problem.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
I don't think VCS will solve your problem.
Your best bet maybe to abstract out the phone specific functionality as much as possible and/or go with a plugin type model.
I've only had experience with Subversion, CVS, Starteam, and VSS. Branches are a pain no matter what... especially if you have multiple active branches. You won't get around doing constant merges , branch comparisons, and trying to track if you've made a change to all branches.
If you organize your code into some core modules and some phone-specific modules which depend on the core modules then it doesn't really matter which VCS you use. I would recommend a decentralized VCS anyway (Mercurial, Bazaar, Git).
You could consider describing how do you want to achieve what you want (different app versions with different feature sets) to get a more reasonable advice
If you use Perforce, you can use different mappings between the depot and your workspaces and do something like:
depot/
common/
platform1/
someportedfile
platform2/
someportedfile
and have it mapped in your workspace to:
platform1/
someportedfile
common/
platform2/
somtportedfile
common/