In Java, if I making a graphical editing component, should I use twips as the unit of measure or is the twip now obsolete in favor of some other unit?
I want to have a unit that can be used to deliver output to high resolution printers.
You are basically asking for an opinion. Pixels, twips, millimeters, inches do their job and you will always need additional information (like a device's resolution) in order to convert coordinates, lengths and similar. It doesn't really matter if you use twips or, say, millimeters, but you have to be consistent. You should rather prepare for implementing/using the conversion between different measurement units than to stick with a specific one.
If you think of printing it out and applying a ruler on the sheet to measure if everything is correct, you wouldn't be better off dealing with twips - or do you have a twips-based ruler? ;) Also, in a conversation with someone else, who may not be familiar with twips, you would have a better communication basis using a measurement unit common for both. So personally, I prefer millimeters in such cases, but the same problems arise, when I talk to someone, who uses inches. You won't be able to make everyone happy.
Finally, it is on you to decide for a strategy. The only rule of thumb I can think of is: Use the most common thing in your domain. If you're doing everything on your own, do what you like. If someone helps you or you prepare something for someone else, you have to be able to talk to this "someone" in a way he/she understands without additional effort of conversion.
These are only some thoughts that came to my mind ad hoc; surely there are lots of further rationales depending on what exactly you are trying to do and what you are planning for the future of your code. Hope this helps.
Related
We are using Jasper Reports to generate reports from our application, based on Oracle DBMS.
The thing works fine, but it is likely we're going to use different paper formats, languages and orientations for the same document, or to add columns and other elements, or have the elements' contents change size.
Doing this in iReport/Jasper isn't easy AFAIU.
If something doesn't work you have to move or resize elements by hand, checking they're of appopriate size and position.
When I was a student I would use LaTeX for typesetting and it could easily handle "reshaping" well. Isn't there something like that?
I heard BRIT doesn't follow the "pixel position" paradigim of Jasper and Pentaho, and as such it strive to handle positioning and, possibily sizing, alone, after the user had specified the document's abstract structure, i.e. what elements are there and their relative position.
EDIT
Forgot to mention: we are looking for a solution that involves as little code as possible. The reasons are manifold, but the most important are:
first: avoid learning another library (we managed to stay away from Jasper's and liked it).
second: giving a tool that even those that aren't programmers, or hardcore ones, could manage.
The lower the entry barrier the better.
For example I know people in the humanities that can pick up LaTeX decently. They could even digest iReport. I don't know of anyone who can do the same with real-world Java.
This question has already been asked at htc files: Why not to use them?, but the answer didn't answer anything really.
The question is, why is something like CSS3 PIE
not in use on many sites? I'd expect smaller ones to not know about it, but the one that caught my eye was Twitter, who doesn't use it.
Is it because it's not standard? Or does it cause a noticeable slow-down of the site?
Thank you for any responses.
I can't speak for everyone, but my sense is that you don't see tools like these in use on large sites because:
1) They do incur a certain performance cost. CSS3 PIE in particular starts to create a noticeable rendering delay after use on about two dozen elements (in my experience, YMMV.) For that reason its use on large pages might cause a larger rendering delay than the time saved downloading image assets.
2) They start to show bugs with complex DOM changes. Lots of animation, showing/hiding, etc. can sometimes cause PIE to get out of sync.
3) Related to #2, the added layer of abstraction (and its associated bugs) can become a detriment on large development teams with a complex codebase. If you start spending more time debugging the abstraction than it would take to simply create rounded corner images, then the tool is getting in the way.
I'm speaking specifically about CSS3 PIE here because it's near and dear to me (I'm its creator), but similar caveats apply to other polyfills like Selectivizr. This goes for any tool: you always have to evaluate the pros/cons for your specific needs. For example I wouldn't recommend PIE for a high-traffic, performance-critical, highly interactive site like Twitter for the reasons stated above, but it really shines on simpler more static designs.
...Another thought is that it's perfectly valid in many cases to simply let IE degrade to square corners etc. This is always the preferred approach IMO, if possible given your particular situation. So in that case it's not due to any evaluation of the tool, but just a decision that what the tool provides is simply not needed in the first place. :)
I wonder what sort of things you look for when you start working on an existing, but new to you, system? Let's say that the system is quite big (whatever it means to you).
Some of the things that were identified are:
Where is a particular subroutine or procedure invoked?
What are the arguments, results and predicates of a particular function?
How does the flow of control reach a particular location?
Where is a particular variable set, used or queried?
Where is a particular variable declared?
Where is a particular data object accessed, i.e. created, read, updated or deleted?
What are the inputs and outputs of a particular module?
But if you look for something more specific or any of the above questions is particularly important to you please share it with us :)
I'm particularly interested in something that could be extracted in dynamic analysis/execution.
I like to use a "use case" approach:
First, I ask myself "what's this software's purpose?": I try to identify how users are going to interact with the application;
Once I have some "use case", I try to understand what are the objects that are more involved and how they interact with other objects.
Once I did this, I draw a UML-type diagram that describe what I've just learned for further reference. What happens after depends on the task I've been assigned, i.e. modify the code, document the code etc.
There is the question of what motivation do I have for learning the new system:
Bug fix/minor enhancement - In this case, I may focus solely on that portion of the system that performs a specific function that needs to be altered. This is a way to break down a huge system but also is a way to identify if the issue is something I can fix or if it is something that I have to hand to the off-the-shelf company whose software we are using,e.g. a CRM, CMS, or ERP system can be a customized off-the-shelf system so there are many pieces to it.
Project work - This would be the other case and is where I'd probably try to build myself a view from 30,000 feet or so to know what are the high-level components and which areas of the system does the project impact. An example of this is where I'd join a company and work off of an existing code base but I don't have the luxury of having the small focus like in the previous case. Part of that view is to look for any patterns in the code in terms of naming conventions, project structure, etc. as this may be useful once I start changing some code in the system. I'd probably do some tracing through the system and try to see where are the uglier parts of the code. By uglier I mean those parts that are kludge-like and may have some spaghetti code as this was rushed when first written and is now being reworked heavily.
To my mind another way to view this is the question of whether I'm going to be spending days or weeks wrapping my head around a system like in the second case or should this be a case where it hopefully takes only a few hours, optimistically that is, to get my footing to make the necessary changes.
At one point while traveling the web, I came across a great page which contrasted the clarity and terseness of different methods of doing a sequence of operations without having to make a bunch of throwaway variables, e.g., Var1, Var2, Var3. It tried list comprehensions, folds, maps, etc. For some reason, now matter what I google, I can't find it again. Anyone have any idea what I'm talking about? Or want to explore the topic anyway?
Your question doesn't make much sense.
List comprehensions, fold, and map aren't for avoiding variables (nor are they interchangeable), they're the right ways to process data depending on what you're trying to do.
This is the article you were looking for:
http://erlanganswers.com/web/mcedemo/VersionedVariables.html
It is probably more of an art than a science. In a nutshell my advice is to lean away from using throw-aways as a general habit, but equally, do not be afraid of using them intelligently and sparingly where you feel appropriate or necessary.
When you are starting to learn then by all means use throw-away variables if it helps you break things down into understandable chunks. But try to break away from that sooner rather than later, as using throw-aways may at times make your code harder to maintain and modify. On the other hand, even when you are experienced you may sometimes find that it is worth using throwaways for the same reason : keep things readable and manageable for less experienced programmers. Purists may say that you should never use them, but I believe that when you consider the lifetime costs of software maintenance it is important to remember that readability is very important. Maybe this argument doesn't apply if you are lucky enough to work in an environment that only hires the best of the best, but for the rest of us that's simply not a reflection of the real world.
The bottom line : what is "right" depends on your skill level, the skill level of your peers, what you are doing, and the likely volatility, complexity, and lifetime of the code. Use your best judgement.
In response to the answer saying the question doesn't make sense, you would certainly think it made sense if you saw the article to which I'm referring. The point is to elegantly process a series of statements without redundant intermediate variables. Zed is right on target. I really wish I could find the original link because it was super detailed and went through 5 or 6 methods, some of which were referenced from the erlang mailing list, and weighed the pros and cons of each.
If you're writing something by yourself, whether to practice, solve a personal problem, or just for entertainment, is it ok, once in a while, to have a public field? Maybe?
Let me give you an analogy.
I come from a part of the world where English is not the primary language. But it’s necessary for all things in life.
During one of those usual days during my pre-teen years I said something very funny in English. Then my Dad said, “Son, think in English. Then you’ll get fluent”
I think it applies perfectly to this situation.
Think,try and question best practices in your playground. You will soon realize what’s best for what.Why are properties needed in the first place. Why should this be public? Why should I not call a virtual member from the constructor? Let me try using "new" modifier for a method call. What happens when I write 10 nested levels of if-then-else and try reading it again after 10 days. Why the heck should I use a factory pattern for a simple project. Et cetera.
And then you’ll realize without shooting at your foot, why design patterns are patterns...
I think it's reasonable if you're consciously throwing the code away afterwards. In particular, if you're experimenting with something completely different, taking shortcuts makes sense. Just don't let it lead to habits which cross over into "real" code.
Violating general principles is always "ok"! It is not an error to violate a principle but it is a trade off. The cost of not writing clean code will be higher the longer your software will survive. My take on this is: If in doubt make it clean!
Of course it's OK. It's your code, you can do whatever you want with it. Personally, I try to stick to good practice also in my private code, just to make it a natural habit so I don't have to think about it.
The short answer is yes, if you believe that you're gaining a lot by making things public instead of private with accessors you are welcome to do so. Consistency, I think, is the biggest thing to keep in mind. For instance, don't make some variables straight public, and some not. Do the same across the board if you break with best practices. It comes back to a trade-off. Almost no-one follows many of the IEEE specs for how Software Engineering should be executed and documented because the overhead is far too great, and it can get unmanageable. The same is true for personal, light-weight programming. It's okay to do something quick and dirty, just do not get used to it.
Public members are acceptable in the Data Transfer Object design patter:
Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods.
One of the key advantages of OOP is for scaling and maintainability. By encapsulating code, one can hide the implementation. This means other programmers don't have to know the implementation, and can't change your object's internal state. If you language doesn't support properties, you end up with a lot of code which obfuscates and bloats your project. If the code doesn't need to be worked on by multiple programmers, you aren't producing a reusable component, and YOU are the maintenance programmer, then code in whatever manner allows you to get things done.
Does a maid need to make his/her own bed in the morning in order to practice properly making a bed?
Side note: it also depends on the language:
In Scala, according to the Uniform Access Principle, clients read and write field values as if they are publicly accessible, even though in some case they are actually calling methods. The maintainer of the class has the freedom to change the implementation without forcing users to make code changes.
Scala keeps field and method names in the same namespace.
Many languages, like Java, keep field and method names in separate namespaces.
However, these languages can’t support the uniform access principle as a result, unless they build in ad hoc support in their grammars or compilers.
So the real question is:
What service are you exposing (here by having a public field)?.
If the service (get/set a given type value) makes sense for your API, then the "shortcut" is legitimate.
As long as you encapsulate that field eventually, is it ok because you made the shortcut for the "right" reason (API and service exposure), versus the "wrong" reason (quick ad-hoc access).
A good unit test (thinking like the user of your API) can help you check if that field should be accessed directly or if it is only useful for internal development of other classes within your program.
Here's my take on it:
I'd advise avoiding public fields. They have a nasty habit of biting you later on because you can't control them. (The word you're looking for here is volatility.) Further, if you decide to change their internal implementation, you have to touch a lot more code.
Then again, that's what refactoring tools are for. If you have a decent refactoring tool, that's not nearly so difficult.
There is no silver bullet. I can't repeat this enough. If you have work to do, and you need to get it done in a hurry, writing one line of code instead of eight (as is the case in Visual Basic) is certainly faster.
Rules were meant to be broken. If a rule doesn't necessarily apply in your case, don't use it. Design patterns, coding guidelines, laws and best practices should not be treated as a straightjacket that requires you to needlessly complicate your code to the point where it is enormously complex and difficult to understand and maintain. Don't let someone force you into a practice just because it's popular or "standard" when it doesn't fit your requirements.
Again, this is a subjective opinion, and your mileage may vary.