What are the major differences between Rails 3 built-in logger and Log4r? It seems to me that Rails 3 logger gives you everything that you need.
Built-in logger is good enough for both development or production environment. especially at the very beginning stages of your project, you don't need to waste time to testing and choose an appropriate tool or library to do the logger job. You can concentrate on the project itself. the simliar situation like "erb" or "haml", "sass" or "less", "coffeescript" or "plain javascript", etc...
Log4r allow you to format your logs easily through configuration file. its a good built-in logger alternator when you real need it.
http://log4r.rubyforge.org/
What Log4r Is
Log4r is a comprehensive and flexible logging library written in Ruby
for use in Ruby programs. It features a hierarchical logging system of
any number of levels, custom level names, logger inheritance, multiple
output destinations, execution tracing, custom formatting, thread
safteyness, XML and YAML configuration, and more. Log4r is an adherent
to the philosophy of logging using simple print statements. What Log4r
adds to this philosophy is a flexible way of controling the
information being logged. Log information can be sent to any kind of
destination and with varying degrees of importance. Log4r is designed
so that logging statements can remain in production code with almost
no extra computational cost.
Log4r intends to be easy to use and configure, no matter the
complexity. Casual scripts can use Log4r right away with minimal
configuration, while more sophisticated applications can set up a
structured configuration file in XML or YAML. Comprehensive
documentation is provided, with a user's manual, a reference API, and
over a dozen examples. Log4r attempts to abide by the Principle of
Least Surprise, which means that it works as intended at all points.
Log4r was inspired by and provides much of the features of the Apache
Log4j project, but is not a direct implementation or clone. Aside from
superficial similarities, the projects are not related in any way and
the code base is completely distinct. Log4r was developed without even
looking at the Apache Log4j code.
Log4r is an Open Source project and intends to remain that way. The
Log4r license is similar to the Ruby Language license. It resides on
this page and in the distribution in a file named LICENSE.
Related
KIE Workbench comes with a set of asset types, e.g. Guided Rule, Form, Business Process, etc. I would like to extend KIE/JBPM with a new type of asset that is specific to my business. This asset would require to be included in the packaging, be able to expose an additional endpoint and extend the KIE Workbench user interface.
I haven't been successful in finding this option in the documentation as of yet. In the mean time I started analysing the sources, but given the size of the project, reverse engineering this will take quite some time.
This question is about KIE 7.x
We have working aurelia based application.
How do we migrate it to use aurelia-cli?
I can speak to this after doing it myself and being involved actively in another project. The project I converted was stamp-web The best way is to take your project
Copy it to a backup folder
Run "au new" and go through the process of creating your target application and setup the values (ES6, Jasmine etc.)
Copy over your src/templates/css piece by piece. I recommend starting with stuff like helpers, utilities etc. (stuff that has very little dependencies). As you go bring in the OSS dependencies into package.json as well as modify the Aurelia.json to reference them correctly in the vendor (or other bundle)
i18n needs some special configuration (so beware of that) - look to their website or my app stamp-web as an example (I have a bunch of configs that work for various OSS libraries)
Keep going as you build up and test your app.
If you look at what I did in stamp-web on the July 16, 2016 commit it will show many of the changes. I also decided to follow the resource convention for generated objects (like elements, value-converters). This is not needed, and I converted VERY early in the process - as you can see by the date.
Having said all that, I am involved in a much larger project (a corporate affair where we have been working on a large web-app for 10+ months with a team) and porting it over has been painful. It is likely 3x bigger than stamp-web, but the troubles we have had there is because we have a central "library" of widgets, services etc. as well as build tooling that was used to build apps. The app conversion was simple, but getting the apps to use the library itself has been a very large challenge. This is largely because while the CLI seems powerful, we have run into some odd behaviors (we have filed bugs as appropriate) as well as general lack of documentation in regards to the Aurelia.json and require JS syntax.
However, when you get it converted your app will load WAY faster than the SystemJS loaded apps..... it is almost.... impressive how quick is loads.
Initial tracing can be a pain on a large app, however updates and watches are seamless.....
Good luck!
I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.
I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to
Be able to write libraries or self-containing code that can bring from one project to another
Share my code with others as open sourced projects
Prevent myself from writing messy code that does not follow proper structure
Use a high warning level. Build cleanly.
Remove all static analyzer issues.
Write some unit tests.
Keep the public interfaces small.
Specify your library's dependencies (e.g. minimum SDK versions and dependent libraries).
Compile against multiple/supported OS versions regularly.
Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
No global state (e.g. singletons, global variables).
Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
Document your public interface (maybe your private one too…).
Define a precise and uniform error model.
You can never have enough error detection.
Set very high standards -- Build them for reuse as reference implementations.
Determine the granularity of the libraries early on. These should be very small and focused.
Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
Minimize visible dependencies (e.g. don't #import tons of frameworks which could be hidden).
Be sure it compiles without the client needing to add additional #imports.
Don't rely on clients putting things in specific places, or that resources will have specific names.
Be very conservative about memory consumption and execution costs.
No leaks.
No zombies.
No slow blocking operations on the main thread.
Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
Study, use, and learn from good libraries.
Ask somebody (ideally, who's more experienced than you) to review your code.
Do use/exercise the libraries wherever appropriate in your projects.
Fix bugs before adding features.
Don't let that scare you -- it can be really fun, and you can learn a lot in the process.
There are a number of ways you can reuse code:
Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.
That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.
Simply put, if you're using maven, should you treat the maven layout as the gold standard, or should you convert your layout to fit your tooling (WASD, myEclipse, RAD, etc.)?
Realizing that maven is configurable and you can override the defaults in the Super POM, I'm attempting to determine if I should change the layout to support specific tools that are in house, or attempt to make those tools recognize the maven layout. One thing to consider is the eventual integration of continuous build tools, as well as the different IDEs in play. MyEclipse is currently being used, but word is that they are not going to renew licenses in 6 months.
The first question I asked regarding this sort of thing was a bit too specific and one-sided.
Maven is following the "Convention over Configuration" principle, which means that if you are following their conventions, then you do not need to redefine basic information, such as your project structure.
As far as I am concerned, I prefer to have the shortest pom.xml I can write, and I don't like to define the information like where to find the sources, the resources, and so on.
In addition to that, having the same structure for several projects is a evident benefit, especially if you have many applications to manage. It also helps new developers to understand the application if it follows some conventions...
Like all "best practices," take it for what it's worth. As you point out, IDEs may have a particular project structure that they like - since most of your development is actually done in the IDE, that's how developers will actually think about problems.
If you standardize your shop around a standard project structure, you can always define that common structure in a company wide parent POM file.
The default project structure works, so don't waste time debating and deciding on a different project structure and then configuring maven to use it.
Currently I get to edit a lot of Spring.NET XML files, and I do find this work to quite repetitive and, frankly boring.
Most of the stuff I do is sort of 'refactoring' - generalising XML declaration for instances and "inheriting" from those generalised structures to declare more specific ones.
As I said, it's a no-brainier type of task but it does require a lot of attention and concentration and it's easy to make a mistake.
I would imagine that a lot of editing of Spring.NET xml files can be automated with a tool similar to ReSharper.
Can you recommend anything?
In the latest spring release (1.3-you can find files for ReSharper to help you with the XML files, though I haven't used them yet.
You might also want to look into Recoil which tries to avoid xml files and allows you to configure a Spring.NET powered application via code.
One of my clients uses Spring.NET quite extensively. I found the process of modifying the configuration files, starting the application and then getting a single, cryptic Spring.NET error at a time quite tedious. So I built a noddy validator that is now run as a post-build step on all executable projects. This will not help you with the actual refactoring itself but should let you identify any errors more quickly.
You can give it a bash by downloading it from BitBucket. I only developed the product until it catered for our use-cases so you may find that you will have to extend it to meet your needs.