In this phrase we have a bold term using the B tag
In this phrase we have a strong term using the strong tag
This phrase, we have a italic term using the i tag (non semantic)
This phrase, we have a emphasis term using the em tag (semantic)
WE can create a marked text using the mark tag
And in the other paragraph, we have other marked text in the end.
We are creating a big text and a small text in this paragraph
we can mark a text as deleted to indicate to be read, but not considered
We can mark a text as inserted to give emphasis and indicate that was added later
Underline text exists too with u tag (non semantic)
To insert text like x20+3
To insert text like H2O


The C++ standard library does not provide a proper date type. C++ inherits the structs and functions for date and time manipulation from C. To access date and time related functions and structures, you would need to include <ctime> header file in your C++ program.
There are four time-related types: clock_t, time_t, size_t, and tm. The types clock_t, size_t and time_t are capable of representing the system time and date as some sort of integer.
The structure type tm holds the date and time in the form of a C structure having the following elements:
struct tm { int tm_sec; // seconds of minutes from 0 to 61 int tm_min; // minutes of hour from 0 to 59 int tm_hour; // hours of day from 0 to 24 int tm_mday; // day of month from 1 to 31 int tm_mon; // month of year from 0 to 11 int tm_year; // year since 1900 int tm_wday; // days since sunday int tm_yday; // days since January 1st int tm_isdst; // hours of daylight savings time }
Following are the important functions, which we use while working with date and time in C or C++. All these functions are part of standard C and C++ library and you can check their detail using reference to C++ standard library given below.
| SN | Function & Purpose |
|---|---|
| 1 | time_t time(time_t *time);
This returns the current calendar time of the system in number of seconds elapsed since January 1, 1970. If the system has no time, .1 is returned. |
| 2 | char *ctime(const time_t *time);
This returns a pointer to a string of the form day month year hours:minutes:seconds year\n\0. |
| 3 | struct tm *localtime(const time_t *time);
This returns a pointer to the tm structure representing local time. |
| 4 | clock_t clock(void);
This returns a value that approximates the amount of time the calling program has been running. A value of .1 is returned if the time is not available. |
| 5 | char * asctime ( const struct tm * time );
This returns a pointer to a string that contains the information stored in the structure pointed to by time converted into the form: day month date hours:minutes:seconds year\n\0 |
| 6 | struct tm *gmtime(const time_t *time);
This returns a pointer to the time in the form of a tm structure. The time is represented in Coordinated Universal Time (UTC), which is essentially Greenwich Mean Time (GMT). |
| 7 | time_t mktime(struct tm *time);
This returns the calendar-time equivalent of the time found in the structure pointed to by time. |
| 8 | double difftime ( time_t time2, time_t time1 );
This function calculates the difference in seconds between time1 and time2. |
| 9 | size_t strftime();
This function can be used to format date and time a specific format. |
Consider you want to retrieve the current system date and time, either as a local time or as a Coordinated Universal Time (UTC). Following is the example to achieve the same:
#include <iostream> #include <ctime> using namespace std; int main( ) { // current date/time based on current system time_t now = time(0); // convert now to string form char* dt = ctime(&now); cout << "The local date and time is: " << dt << endl; // convert now to tm struct for UTC tm *gmtm = gmtime(&now); dt = asctime(gmtm); cout << "The UTC date and time is:"<< dt << endl; }
When the above code is compiled and executed, it produces the following result:
The local date and time is: Sat Jan 8 20:07:41 2011 The UTC date and time is:Sun Jan 9 03:07:41 2011
The tm structure is very important while working with date and time in either C or C++. This structure holds the date and time in the form of a C structure as mentioned above. Most of the time related functions makes use of tm structure. Following is an example which makes use of various date and time related functions and tm structure:
While using structure in this chapter, I'm making an assumption that you have basic understanding on C structure and how to access structure members using arrow -> operator.
#include <iostream> #include <ctime> using namespace std; int main( ) { // current date/time based on current system time_t now = time(0); cout << "Number of sec since January 1,1970:" << now << endl; tm *ltm = localtime(&now); // print various components of tm structure. cout << "Year" << 1900 + ltm->tm_year<<endl; cout << "Month: "<< 1 + ltm->tm_mon<< endl; cout << "Day: "<< ltm->tm_mday << endl; cout << "Time: "<< 1 + ltm->tm_hour << ":"; cout << 1 + ltm->tm_min << ":"; cout << 1 + ltm->tm_sec << endl; }
When the above code is compiled and executed, it produces the following result:
Number of sec since January 1, 1970:1294548238 Year: 2011 Month: 1 Day: 8 Time: 22: 44:59


A year or so ago, I received a letter from an old friend of mine, formerly a professor at Benjamin Thompson University, now a Dean. His new title is Director for Special Policy or something like that. BTU was one of the first "real" universities to realize the terrible dilemma that any business faces when it is saddled with an aging infrastructure and eroding market share.  They were very good at saying where they wanted to go, but somehow, they were having trouble getting there. So he wrote me a letter asking for my advice and response to the annual draft of the policy document.
Here is what I wrote in e-reply:
[snip]
Dear Pete:
Look, the first and most important rule of university administration
for the future is: if it is possible to provide an educational service
by telecommunication, then *don't* build an infrastructure to provide
that same service. After all, buildings, facilities and equipment
cost a ton of money to construct, maintain, and refurbish.
Secondly, in cases where infrastructure must be created,
adjust your fees to assure that primary users are primary providers.
Subsidize only at the behest of wealthy patrons or the government;
facilities that prove to be unprofitable should be sold off to a competitor.
What kinds of facilities remain? Largely, any activity that is physical.
For example, to teach someone how to play tennis,
one needs a tennis instructional facility where both teacher
and student can work up a sweat.
There's only so much one can do with bioengineered telepresence, after all.
HMD/MSE technology can only go so far, at least for now.
Here, the university must assess whether this is an infrastructure
that it wants to build, knowing that it will be competing with private courts and lanes.
The university must adjust its expectations to the specifics of the marketplace.
If it does build and operate a facility, the life-cycle costs must be passed on to the users.
But obviously, fees cannot be significantly higher than those charged
by other corporations unless the university adds value in some way.
So adding value is the key. The real world university of the future will probably
become very much a social club offering state-of-the-art
sports and entertainment practice facilities and clinics.
It will also become a fun place to go to engage in all kinds of social events
that are not necessarily mainstream.
(if they were, they would likely be offered by someone else more cheaply).
In fact, the only thing that will provide the university of the future
with the high margin revenue it needs to survive and expand
is that its employees will be creative and willing to take risks
in stretching the boundaries of art, music, theater, performance & exhibitions,
etcetera. New services and ideas, by definition, have no
established pricing structure -- so when something becomes
sufficiently mainstream and competition arises,
that will be your signal to sell off a facility to private interests and try something new.
The real world university will also provide some facilities
that abet research and development in medicine, science and technology.
After all, despite some incredible gains in modeling software,
there are still some things that need to be tested physically,
if for no other reason than to assure engineers that their
modeling assumptions about such things as airflow or
tensile cohesion are really true.
Some systems, such as biological organisms, are so complicated
that modeling them is well-nigh impossible, and again,
a physical laboratory is often necessary to test new methods and products.


When there is a higher purpose, reading that book is what stays in the way!
Agreed!
Isolated room, at the desk. This is work you’re doing.
Get into the flow.
Pen and Paper at hand (fundamental to the method)
Target the WHY. Why are you doing this? No, really, why? Project? Future job? Writing a book?
There must be a good reason for reading this book. 5 WHYs it if needed.
WHYs that do not fly: Because reading is good for me. Because others say it’s cool. Because it’s a good example for the kids. You name it.
All valid reasons but not enough. You must do better than this.
Now, understand that this book stays in the way. It sits between You and your Purpose.
Your goal here is getting it done. No excuses. Remember your WHY.
This is the mindset. You have limited time. Thousands other books are waiting.
You need to get it done.
You’re after 20% of this book that makes 80% of the difference.
Your goal is to extract information as fast and efficient as possible and move on.
Speed read through it like you mean it. Use all the tips on speed reading but don’t obsess over it.
Distill knowledge and take notes. Decide what’s important to you. And cut out the rest.
Be merciless. A paragraph, or a page per chapter might be to much already.
There’s no standard here, decide on the parts worth insisting on, but keep it pragmatic.
The notes are the final artefact, that’s why you’re here, make them matter.
You decide what’s truly important.
There are lots of excellent books out there on a given subject.
Different authors, different perspectives, most of them worth reading.
But there’s limited time.
It’s better to distill 80% of the knowledge that matters from ten books in a week,
than 100% of the knowledge from one book in that same time.
And yes, this is also one method of fighting information overload.
If your purpose is leisure, relaxation, then it’s fine to do it on the couch, wine glass and all.
You probably don’t want to speed read through “A Song of Ice and Fire”, or “Harry Potter”, right? Unless…
Some books are meant to be read in a relaxed setup. And that is fine. But make the difference between them and the rest.
Writing the notes down will store it to your brain and you’ll be able to trigger that knowledge out later when looking over them.
Deciding on what to cut out is important.
Authors will fall in love with their ideas and go around it 10 times to make the point. And it’s all fine.
But that’s their problem. You’re after the essence here.
You’re in control. Remember there are thousands other books out there, as good as this one or better,
all waiting for you to read them.
All of those books staying between you and your higher purpose.
And there's limited time.
Q: What's with the wary attitude, dude? It’s like you’ve declared war to books!
A:
Have you browsed through the Amazon store yet?
On a subject you care about, or is deeply important to you?
Walked into a library recently? What did you find?
Hundreds? Thousands of books? What are we going to do with all that?
There’s two ways to go about it:
1.) Get lost and lose hope.
2.) Conquer them.
Q: What's your take on books?
A:
There’s an inherent comfortable feeling that a book instills in the reader. Get rid of it.
As soon as the comfort zone is established, learning becomes inneficient. Fight it by Reading with Purpose.
There's tension associated with learning. Embrace it.
You will fall in love with that book and want to hug it. Make it quick if you must.
And move on. If you loved it so much, pick it up later and read it for leisure. Sleep with it.
Q: Where is this all coming from?
A:
altMBA forced me to transform my reading handicap (very slow reader) into a beautiful constraint.
I’m not kidding myself for having invented something here. I’m merely highlighting what we’ve known for a long time.
Ready to share your Reading with Purpose experience?


→
Black Box
→
Discovering how things work: a resource for the frugal, self-taught computer scientist.
Home
About
Odds and ends
Projects
Interesting websites


The newest graphcis card technology presented by Nvidia
RTX 2000 Series
Presented to the world in| British Columbia | Alberta | Saskatchewan | Manitoba | Ontario | Quebec | Nova Scotia | Newfoundland & Labrador | Prince Edward Island | New Brunswick | |
| Population | 4,648,055 | 4,067,175 | 1,098,352 | 1,278,365 | 13,448,494 | 8,164,361 | 923,598 | 519,716 | 142,907 | 747,101 |
| Capital City | Victoria | Edmonton | Regina | Winnipeg | Toronto | Quebec | Halifax | St. John's | Charlottetown | Fredricton |
What are the names, in ascending order, of the first two graphics cards in the gtx series from Nvidia


+91<PHONE_NUMBER>
Our Project is on the topic "ONLINE COURSE & MESS REGISTRATION SYSTEM"This System Will Allow Students With Ease to Perform Various Tasks like Course Registration, Mess Registration, Semester Details, Faculty Advisor Help and many more.....
CONTACT ME:-sunny.arora2015@vit.ac.in(+91)9585378818
CONTACT ME:-swarnim.gupta2015@vit.ac.in(+91)9790018226
CONTACT ME:-saurav.bhattacharya2015@vit.ac.in(+91)9790086340


Confidentiality-During Review Process: Reviewers are solely responsible for the submitted manuscripts for review and those are considered as confidential files and should not discussed with others, except with the Editorial team or Editorial staff members until review process completed.
Standards of Objectivity-During review process the Reviewers should conduct reviews objectively. Personal criticism of the author is unprofessional or inappropriate.
Fast-Track Reviews As our Journal publishing articles on monthly basis the reviewers are requested to finalize the review process in stipulated time provided. If the reviewer is busy with his academic activities and any other commitments please let us know immediately and such time refuse the invitation for review process.
Promptness Any reviewer who believe that he/she is not qualified to review the received research work should inform the Editor-in-Chief promptly.


"Metteur-en-scene, director. The point is not to direct someone but to direct oneself." -Robert Bresson, Notes on the Cinematographer
There seems to be a general disaster zone that the majority of actors-turned-directors wander into. It is to actually try to direct the film (usually according to some miniscule fraction of theory or method that they have recently misunderstood.) A number of examples come to mind of which, Buscemi citing Cassavetes and Hanks naming Kurosawa, Kubrick and Eisenstein in the same breath are only the most notorious examples. Anyone who saw, Trees Lounge or That Thing You Do knows that despite their differences the films share an alarming capacity for self-delusion. Flawed assumptions, heavy-handed referencing and all around awkward articulations are the hallmarks of such films which, incidentally, are not without a lot of company. Gary Oldman's latest film Nil by Mouth, avoids such pitfalls by recognising the number one job of the actor-director: to marshall their unique talents (knowledge of performance and interpretation) in a coherent effort. No flashy loud camera work (Albino Alligator), no overpriced contrived production values (Braveheart) and no heavy handed ludicrous symbolism (Dead Man Walking). Gary Oldman, like accomplished actor-directors before him (epitomised by the late John Cassavetes, and not unlike the more recent efforts of Sean Penn) makes a number of very specific directorial decisions guided by what he believes the crux of cinematic representation to be. Just as Errol Morris who studied Philosophy, or Antonionni who studied Political Economy, employ directorial methods that privelege their given expertise. In the case of the actor-director this expertise is clear, and it is often insecutrity about acknowledging such limits that lead actor-directors astray. Oldman has reminded us that when such errors are not made the results are complex and astounding films.
Nil by Mouth chronicles the dynamic between a lower-class London family (This is all you really need to know). Oldman wisely, keeps the plotting down to a minimum concentrating instead on accurately rendering the complexity of the characters and their relationships. For much of this he defers to the actors (all of whom play superbly) by the specific camera decisions he makes. Throughout the film, Oldman's camera is never in the wrong place but more importantly the scale of the shots is perfect. Vitrually the entire film is shot in close and medium shots through long lenses that truly crush the depth of field. There is also inly a very selective use of two-shots and group shots in the film. To call the result clasutrophobic and uncomfortable is a gross understatement. The implications of this technique for the narrative are manifold: it alludes to the enclosed world of the characters as well as establishing a number of key associations between these characters. This gives them a first layer to work with. More importantly, howver, the longer lenses, necessarily allowed Oldman to move away from the actors freeing up their physical space despite the very particular diegetic space (oweing to the reduced depth of field.) It is a technique not unlike the one Cassavets uses in A Woman Under the Influence. The result of these decisions is apparent in the job the actors do which I'v already said is excellent. Oldman could have chosen any number of avenues by which to shoot these people, all of which would have left a flawed product that udermined the strength of the performances. Although, I don't think every film should be made this way, when it is an actor at the helm, the technique truly seems perfect.
Over and above these stylistic elements the narrative of Nil by Mouth is extremely assured. With a running time of just over two hours, Oldman clearly had no doubts about the events to be included in the portrayal. The film is apparently based on autobiographical events, which shows in the film's authenticity. The plotting is kept to a minimum but this does not mean the film was not carefully scripted. There are a number of crucial speeches, which are placed at specifc times in the film for specific reasons. In a number of cases Oldman foregoes dramtatic efficiency in order to convey a mood uf unese and discomfort. The prominence of the unique South Londin accent is only the ost prominent example of this. The characters seem incapable of not talking, as if constantly nervous and hiding something. Even towards the end of the film, in a lengthy scene of Ray left to his own devices this tendency does not stop. The scene is deftly edited as to have Ray almost talking with or at (not to) himself. This underscores some of the ambiguity with which the Ray husband is treated. Such a treatment is genuine in a way that a film like Bastard from Carolina could not hope to be.
I am not sure if Oldman intends to direct other projects or if this was a one time effort to exorcise a number of demons that the actor has harboured. One source (I can't remeber who) has said that Oldman was offended by the apparent glamourising of street and drug culture in Trainspotting and thus finally decided to commit his idea to celluloid. The accusation is a common one that I think is unfair but we can be thankful that Oldman chose to respond in the manner that he did. We can only hope more actors show such poise in their future directing efforts..
-- -Omar Odeh http://www.geocities.com/Hollywood/Theater/3920
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Inflection
The Inflection API reduces the amount of boilerplate code by (virtually) extending
the Java type system with so-called "class views". Key appliations include serialization
and persistence (e.g., JSON, JPA, Hibernate, etc.) in web applications as well as interface
adapters for technical interfaces.
For example, given a Person class it is possible to define the class views
PersonSimple and PersonComplex as follows:
Instances of Person can then be cast to PersonSimple and PersonComplex like this:
Person p1 = new Person();
p1.setFirstName( "John" );
// p1, p2 and p3 all point to the same object, but have different structures.
PersonSimple p2 = Inflection.cast( PersonSimple.class, p1 );
p2.getFirstName(); // Result is "John".
p2.setFirstName( "Frank" );
PersonComplex p3 = Inflection.cast( PersonComplex.class, p2 );
p2.getFirstName(); // Result is "Frank".
p1.getFirstName(); // Result is "Frank".
Click on the link below to try it out or to found out more.
Goto Project Homepage


Appcelerator
Copyright(c) 2011-2012 by Appcelerator, Inc. All Rights Reserved. Please see the LICENSE file included in the distribution for further details.


Follow this link to confirm the update of your email from {{ .Email }} to {{ .NewEmail }}:
Make it {{ .NewEmail }}


Issue 5878: proposal for a command line method: include(url)
Steps to reproduce
- Open Firebug
- Enable and switch to the Console panel
- Type:
include("./myScript.js");
- Type:
window.a
- The console should display:
1
- Type:
include("./myScript.js", "myScript");
- Type:
window.a
- The console should display:
2
- Type:
include()
- The console should display a table containing at least this line:
- Right-click on "myScript" and select "Import myScript"
- Type:
window.a
- The console should display:
3
- Right-click on "myScript" and select "Copy Location"
- The location of the script should be copied
- Type:
include("./myOtherScript.js", "myScript");
- Type:
include();
- The line of step 10 should be replaced by this one:
- Type:
include(null, "myscript");
- Type:
include()
- The line of step 18 should have disappeared


Sends a message to all of a topic's subscribed endpoints. When a messageId is returned, the message has been saved and Amazon SNS will attempt to deliver it to the topic's subscribers shortly. The format of the outgoing message to each subscribed endpoint depends on the notification protocol.
To use the publish action for sending a message to a mobile endpoint, such as an app on a Kindle device or mobile phone, you must specify the EndpointArn for the TargetArn parameter. The EndpointArn is returned when making a call with the create-platform-endpoint action.
For more information about formatting messages, see Send Custom Platform-Specific Payloads in Messages to Mobile Devices .
See also: AWS API Documentation
publish
[--topic-arn <value>]
[--target-arn <value>]
[--phone-number <value>]
--message <value>
[--subject <value>]
[--message-structure <value>]
[--message-attributes <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
The topic you want to publish to.
If you don't specify a value for the TopicArn parameter, you must specify a value for the PhoneNumber or TargetArn parameters.
Either TopicArn or EndpointArn, but not both.
If you don't specify a value for the TargetArn parameter, you must specify a value for the PhoneNumber or TopicArn parameters.
The phone number to which you want to deliver an SMS message. Use E.164 format.
If you don't specify a value for the PhoneNumber parameter, you must specify a value for the TargetArn or TopicArn parameters.
The message you want to send to the topic.
If you want to send the same message to all transport protocols, include the text of the message as a target-arn value.
If you want to send different messages for each transport protocol, set the value of the MessageStructure parameter to json and use a JSON object for the Message parameter.
Constraints: Messages must be UTF-8 encoded strings at most 256 KB in size (262144 bytes, not 262144 characters).
JSON-specific constraints:
- Keys in the JSON object that correspond to supported transport protocols must have simple JSON string values.
- The values will be parsed (unescaped) before they are used in outgoing messages.
- Outbound notifications are JSON encoded (meaning that the characters will be reescaped for sending).
- Values have a minimum length of 0 (the empty string, "", is allowed).
- Values have a maximum length bounded by the overall message size (so, including multiple protocols may limit message sizes).
- Non-string values will cause the key to be ignored.
- Keys that do not correspond to supported transport protocols are ignored.
- Duplicate keys are not allowed.
- Failure to parse or validate any key or value in the message will cause the publish call to return an error (no partial delivery).
Optional parameter to be used as the "Subject" line when the message is delivered to email endpoints. This field will also be included, if present, in the standard JSON messages delivered to other endpoints.
Constraints: Subjects must be ASCII text that begins with a letter, number, or punctuation mark; must not include line breaks or control characters; and must be less than 100 characters long.
Set MessageStructure to json if you want to send a different message for each protocol. For example, using one publish action, you can send a short message to your SMS subscribers and a longer message to your email subscribers. If you set MessageStructure to json , the value of the Message parameter must:
- be a syntactically valid JSON object; and
- contain at least a top-level JSON key of "default" with a value that is a string.
You can define other top-level keys that define the message you want to send to a specific transport protocol (e.g., "http").
For information about sending different messages for each protocol using the AWS Management Console, go to Create Different Messages for Each Protocol in the Amazon Simple Notification Service Getting Started Guide .
Valid value: json
Message attributes for publish action.
Shorthand Syntax:
KeyName1=DataType=string,StringValue=string,BinaryValue=blob,KeyName2=DataType=string,StringValue=string,BinaryValue=blob
JSON Syntax:
{"string": {
"DataType": "string",
"StringValue": "string",
"BinaryValue": blob
}
...}
--cli-input-json (string) Performs service operation based on the JSON string provided. The JSON string follows the format provided by --generate-cli-skeleton. If other arguments are provided on the command line, the CLI values will override the JSON-provided values.
--generate-cli-skeleton (string) Prints a JSON skeleton to standard output without sending an API request. If provided with no value or the value input, prints a sample input JSON that can be used as an argument for --cli-input-json. If provided with the value output, it validates the command inputs and returns a sample output JSON for that command.
The following command publishes a message to an SNS topic named my-topic:
aws sns publish --topic-arn "arn:aws:sns:us-west-2:0123456789012:my-topic" --message file://message.txt
message.txt is a text file containing the message to publish:
Hello World
Second Line
Putting the message in a text file allows you to include line breaks.
MessageId -> (string)
Unique identifier assigned to the published message.
Length Constraint: Maximum 100 characters


Software Engineering Is Good for You.
Software Engineering is – in a few important ways – unlike any other class I have taken here at the University. It carries a writing flag as an upper division CS course and promises to equip us with tools and technologies to make us more employable outside of school. Professor Downing also has a unique way of asking for participation from every student in the class… so pay attention! You will be called on!
The writing bit
I am happy that this blog will force me to improve my writing style via weekly feedback from other students. Writing is an effective form of communication and is essential even as a developer. Whether you’re writing emails, cover letters, or a research thesis, your writing is a reflection of you. Also, well- documented code is essential to a team. Nobody wants to figure out how your code works or doesn’t work the hard way (after weeks of trying)
The software engineering bit
As developers, we have committed to being life-long learners. Technologies may come and go, but it is a valuable skill to keep up with the current best practices. It is equally important to ask why practices may be preferable over another in class, I have already benefitted from it. Software Engineering will be challenging but challenges are valuable learning experiences. It already appears as though Professor Downing will encourage good habits like focusing in class, documenting effectively, reflecting weekly, and diving into new technologies. I’m looking forward to it!
Tip o' the week
This article What You Miss When You Take Notes on Your Laptop from Harvard Business Review was passed along to me this week so I thought I'd do the same. You may benefit from this in class. If nothing else, it's an interesting read.


{{answer}}
The answer has the following constraints. Check all that are violated and do not apply for this answer.
You can leave a feedback for the author.


Search Result:
flag is?
Submit
if input is
^flag{.*.*.*.*.*X
, it takes mach time(because of searching too many cases). So we can search hidden flag using like
solve()
(but it takes some time. please open developer tool to see the log)
solve


Two bodies found at home in Surrey, one is homicide victim
by The Canadian PressSURREY, B.C. — Homicide detectives say they’re investigating after two people were found dead inside a home in Surrey, B.C.
RCMP officers discovered the bodies when they arrived at the home Thursday evening, then called the Integrated Homicide Investigation Team to lead the probe.
Const. Harrison Mohr with the investigation team says early evidence suggests one of the dead was the victim of a homicide.
He says the two people knew one another and police are not looking for any outstanding suspects.
The RCMP did not release the names of the dead.
Police say in a news release that investigators and members of the victim services unit are in the process of reaching out to the family and friends of the people involved.
This report by The Canadian Press was first published Nov. 22, 2019.


Piers Morgan gloats at Dan Walker as ratings war continues
Piers Morgan has reignited his spat with BBC Breakfast’s Dan Walker over viewing figures and is showing no sign of packing it in anytime soon.
Just when thought the pair might put their differences aside for a second, the Good Morning Britain presenter waged another war against his television rival after new stats revealed that the two shows are slowly closing the gap between them.
According to Piers, yesterday’s episode of Good Morning Britain had gained 74,000 viewers and was four share points up when compared to the episode that aired on the same day a year before.
Meanwhile, BBC Breakfast, which is still in the lead, lost 201,000 viewers when compared against the 2018 episode on the same day and was 3.2 share points down.
Overjoyed by the news, Piers took to Twitter to gloat in Dan’s face, despite still coming second place, and said: ‘Hi mate, @mrdanwalker – fancy guzzling this with me to celebrate closest-ever rating gap between @GMB & @BBCBreakfast?’
Advertisement Advertisement
He then went on to ask his followers: ‘Are you one of the growing army of viewers who’ve dumped @BBCBreakfast for @GMB? Tell me why…’
But of course, Piers didn’t stop there. Oh, no.
The dad-of-four, still blown away by Good Morning Britain’s success, then shared a gif of people falling off the edge of a cliff alongside the comment: ‘Incredible that @BBCBreakfast has lost 201k viewers in a year.
‘That’s 1,000 more people switching off every single day @mrdanwalker is on!’
Despite being branded a ‘snivelling sycophant’ by Piers just a few weeks ago, Dan took Piers’ comments regarding the show’s competition in his stride.
Advertisement Advertisement
‘You’ve changed your tune,’ he wrote before making it clear that ‘no one outside our offices care about figures.’
We dread to think what will happen if Good Morning Britain ever overtakes BBC Breakfast…
Breakfast airs weekdays from 6am on BBC One and Good Morning Britain airs weekdays from 6am on ITV.
Got a showbiz story?
If you've got a story, video or pictures get in touch with the Metro.co.uk Entertainment team by emailing us<EMAIL_ADDRESS>calling 020 3615 2145 or by visiting our Submit Stuff page - we'd love to hear from you.


Armageddon (1998)
Director: Michael Bay Cast: Bruce Willis, Billy Bob Thornton, Liv Tyler, Ben Affleck, Will Patton, Peter Stormare, Keith David, Steve Buscemi, Owen Wilson, William Fichtner Screenplay (story, etc.): Jonathan Hensleigh, Robert Roy Pool, Tony Gilroy, Shane Salerno, J.J. Abrams, Paul Attanasio, Ann Biderman, Scott Rosenberg, Robert Towne Producers: Jerry Bruckheimer, Gale Anne Hurd, Michael Bay Runtime: 150 min. US Distribution: Touchstone Rated PG-13: disaster violence, language
By Nathaniel R. Atcheson<EMAIL_ADDRESS>Cinema has been around for about a hundred years now. It's not my job to recap this century every time I talk about a new film, but I'd like to think that I'm beginning to understand the art more as I watch more films from before my time. Recently, I've seen the films of Hitchcock, Capra, Fellini, Godard, Kurosawa, Chaplin, Lang, and many others. Those men were talented artists, and their films reflect their genius. They are likely to be remembered for . . . well, quite a while.
I like this film, too. Yes, it's a disaster-slash-action movie. True, its budget is a lot more money than I'll ever see in my lifetime. And there's not a doubt in my mind that the only reason it was conceived was to make a lot of money. In fact, I bet the producers of Armageddon would have worked towards a lousy film, had they thought it would've been more profitable. I certainly don't care what their intentions were, because Michael Bay (The Rock) is such a skilled director that I doubt he'd ever make a film that is difficult to sit through.
Of course, skillful direction doesn't complete the package, but the rest of Armageddon manages to keep everything together. The story is well-thought out (and perfectly paced to provide for an abundance of action sequences that never feel out of place), the acting is terrific, the script is sharp, and -- get this -- there are characters. Yes, you read that right. Armageddon actually has characters you can care about! If you don't like this film, then you have a problem with the genre itself: Armageddon is as good as a film like this can be.
If you've seen Deep Impact, then you know the basic framework for the story. It turns out that an asteroid the size of Texas is going to strike the earth eighteen days from the start of the film. So, it's up to the U.S. Government to stop it. (Why the U.S. is always exclusively saddled with these problems is never fully investigated.) Their plan -- to send a group of experienced oil drillers up to the asteroid, drill down several hundred feet, and detonate a nuclear warhead within.
The head driller is Harry Stamper (Bruce Willis). His group of men is a colorful bunch, including A.J. (Ben Affleck), Chick (Will Patton), and Rockhound (Steve Buscemi). There's also an interesting triangle formed between A.J., Harry, and Grace (Liv Tyler), who is Harry's daughter. A.J. and Grace are, of course, romantically intertwined, and dad isn't too happy with the situation.
It's absurd to wish for a complicated story in an Event Movie or a Special Effects Movie or whatever it is you'd like to call Armageddon. It's not about story -- it's about viscera and action, and thrills-a-minute, and all that stuff. It's incidental, really, that the story is cohesive and even remotely believable, because most people will be too wrapped up in the explosions to give two seconds' thought to what actually happens. But Bay is the one to congratulate in this case, for he has made a film so entertaining and so visually sharp that I doubt any director could have done it better.
I think most of the budget went to cameras alone, because Bay films every action sequence from about thirty or forty different angles. Take the spectacular opening scene, for instance, in which a meteor shower obliterates New York. A meteor flies out of the sky and crashes into a building, which sends fireballs erupting into the air and cars spinning like tops upon other cars. The action itself might take five seconds in real life, but Bay edits so quickly that we get the same scene in six different ways. I like his quick-edit style, because it's abrasive and exhausting to watch. It's also very loud, and obnoxiously noisy at times. But it's fun to be obnoxious sometimes.
The special effects in this film put every other 1998 blockbuster to shame. Deep Impact, visually, has absolutely nothing on Armageddon, and to offer a comparison between the quality of this film and Godzilla is simply laughable. Special effects are very important in a film like this: if they're not good, then the image is not convincing, and the film doesn't work. Everything here looks bright and explosive -- from the little meteors bursting through skyscrapers, all the way to the shots of the earth through the jutting rocks on the ominously approaching asteroid. The effects that don't look totally real are still a pleasure to behold, and I credit everyone involved for creating the first blockbuster so nice-looking that it actually qualifies as art.
Of course, all of this would add up to little more than an above-average light show, if I didn't get the feeling that Bay cares as much about his characters as he does about his action. The film is two and a half hours long, and not all of that is spent submerged in numbing action. Much of the film is dedicated to developing the various characters' subplots. I won't suggest that these are complex characters, but their problems are real, and the emotions aren't put forth in a sentimental and overbearing way. In fact, there are three or four scenes here that had me pretty choked up, and that's a lot more than I can say about Deep Impact, which was banking on the feel-good parts of its story.
Bruce Willis is terrific, and I'm glad to see him bigger than life again (recent turns in films like Mercury Rising have been very disappointing). Tyler and Affleck are great together, and make a convincing couple -- all of the scenes between them work on a comfortable level. Patton, who is a magnificent actor, thankfully is not wasted here, and the minor subplot revolving around his ex-wife and son is very moving. The comic relief from Buscemi and Peter Stormare (who plays a crazy Russian astronaut) is nifty, and keeps the film lively and funny.
I wasn't challenged to think real hard while watching Armageddon, and I don't mind too much. But the film doesn't insult my intelligence -- it's pitched perfectly to entertain, which is what all it really wants to do. It's not mindless and escapist, but well-crafted cinema. It might have been created for the wrong reasons, but men like Michael Bay have my respect for showing me that they are interested in making something good, in spite of the producers and the budget. I'm not saying that films like this are risky moves. What I am saying is that Armageddon is a big, loud, expensive motion picture that reminds me that art often comes in the strangest of forms.
***1/2 out of **** (8/10, B+)
Visit FILM PSYCHOSIS at http://www.pyramid.net/natesmovies
Nathaniel R. Atcheson
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


WebRI is both a a superlative Ruby documentation generator with a variety of built in templates and a web-based ri-browser which can provided ri documentation dynamically via a webrick server.
Please note that the ri web server and the generation system were developed separately and are not integrated. For this reason the ri server cannot use the templates available to the generators. A future version will remedy this, but it requires the completion of ri2.
Because I am sure you want to see exactly what you are in for before trumping through any more wordage, here is a sampling of WebRI's built-in templates:
OneFish TwoFish RedFish BlackFish LongFish
And that's just for starters. Speaking of which ...
To install we recommend using RubyGems, which is of course straight forward:
$ sudo gem install webri
WebRI provides a webri executable you can use to generate documentation. The interface is identical to rdoc. Use the -T option to specify a template type.
$ webri -T redfish README lib/
You can use rdoc command if you prefer (though in far off future versions this may not be the case).
$ rdoc -T redfish README lib/
WebRI extends RDoc to recognize the templates that WebRI will handle and transfers control to the appropriate WebRI generator accordingly.
WebRI make use of project metadata if it is available. In particular
templates can make excellent use POM metadata.
But if POM is not present, WebRI will fallback to a .gemspec
file,
if one can be found, although the metadata available via a gemspec is more
limited than that available via POM.
WebRI can be used as a dynamic ri browser, either for a single project or for a collection of libraries. Indeed, the WebRI server can be used to browse the entire installed object system --everything documented in your central install locations. To do the this, simply execute webri-server with no arguments and open a browser to the local port designated (see below).
$ webri-server
To browse per-project ri documentation, you will first need to locate the project's ri files, either by locating them in your system installation or by generating them for a project, which can be done using rdoc, eg.
$ rdoc --ri --op "doc/ri" lib/
Sometimes a package will include a convenience script for generating these. Try running 'rake -T', or look for a 'script/' executable that does the job. Usually the generated documentation is placed in either ri/ or doc/ri/. I will use doc/ri/ in the following example, adjust your directory as needed.
With ri files located you can view them with:
$ webri-server doc/ri
You will see a Webrick server start up, informing you of the port being used.
[2008-03-28 12:11:16] INFO WEBrick 1.3.1 [2008-03-28 12:11:16] INFO ruby 1.8.6 (2007-06-07) [x86_64-linux] [2008-03-28 12:11:21] INFO WEBrick::HTTPServer#start: pid=8870 port=8888
In this example we see the port is the default 8888. Simply open your browser and navigate to:
http://localhost:8888/
On the left side of the screen you will see a navigation tree, and the right side contains an information panel.
NOTE: Because ri itself isn't very fast, if you use WebRI against the entire set of installed Ruby libraries it can take a few seconds to load up. (Sure wish FastRI turned out for the better.)
WebRI is a ProUtils project. Development is hosted on GitHub in a very technically sophisticated git repository. You can peruse the source code there, and see just how ruby_way it all is.
To pull the 'webri' repository anonymously, use:
git clone git://github.com/proutils/webri.git
Please, if see any code that doesn't seem ruby_way enough, fork it and fix it or write up an issue ticket, or if all else fails contact Trans.


F.P.Journe Unveils 18-Function Astronomic Souveraine Watch
“Devoted to the contemplation of the stars.”
by Ambrose LeungIn celebration of its first official flagship in Tokyo, independent watchmaker F.P.Journe unveiled its production model of the Astronomic Souveraine watch. This watch packs a hefty 18 functions with over 750 components inside its 44mm case.
Among the 18 functions/complications is a tourbillon with remontoir d’égalité, a sun path with day/night aperture, moon phase, a second time zone, power reserve, minute repeater, annual calendar, and an equation of time. Based on a 15-year-old sketch by François-Paul Journe’s son, this watch was finally brought to life after six years of development.
As with many of F.P.Journe’s watches, the Journe caliber 1619 movement is made from 18-carat rose gold, contains two mainspring barrels, and 68 jewels. The Astronomic Souveraine will be made in extremely limited quantity and sold for $898,000 USD, significantly lower than its previous one-of-one “Blue” prototype which was auctioned for $1.8 million USD at this year’s Only Watch.
For more watch news, a Patek Philippe Just auctioned off for a record $31 million USD.


Timestamp
Request Header Parser
URL Shortener
Exercise Tracker
Metric-Imperial Converter
Issue Tracker
Personal Library
Sudoku Solver
Stock Price Checker
Anonymous Message Board
Build a Pinterest Clone
Chart the Stock Market
Image Search Abstraction Layer
P2P Video Chat Application
Manage a Book Trading Club
Build a freeCodeCamp Forum Homepage Proxy
Show the Local Weather API Proxy


rtc.io Module Reference
The rtc.io suite is made up of a number of modules, which cater for different needs.
Browser Modules
The following is a list of modules that are designed for use within a browser. Each of these modules (unless otherwise specified) is designed to be built into an application using browserify. In our experience, using browserify in conjunction with npm provides a very smooth development experience.
rtc
Bundled module for getting a your WebRTC app up and running quickly.
rtc-quickconnect
Provides a high level wrapper around the lower-level client libraries and is designed to get you building WebRTC applications very quickly.
rtc-dcstream
This is a node compatible stream (streams2) module for working with WebRTC data channels. As per rtc-mesh
this module has been tested against Chrome 32+ and Firefox 26 and shown excellent interoperability.
rtc-tools
The rtc-tools
module is a collection of reusable functions that assist developers wanting to work with WebRTC at a lower level. It is designed to assist with some of the repetitive tasks that are associated with developing WebRTC applications.
rtc-signaller
Signalling is a big part of any WebRTC application. The rtc-signaller
module is the rtc.io suites signalling layer, and is designed as a "transport agnostic" signalling mechanism.
While in almost all our WebRTC implementations we have used websockets for signalling, the rtc-signaller
module is capable of signalling and coordinating connections over any bi-directional communication channel that supports sending text messages.
rtc-core
The rtc-core
module contains some lower-level, shared functionality that is used by most of the above client-side libraries. It assists with cross-browser detection of RTCPeerConnection
classes and other similar functions.
rtc-quickconnect plugins
rtc-mesh
This plugin provides a simple way to use WebRTC data channels to provide synchronized client state using ScuttleButt and it's derivatives.
rtc-sharedcursor
This module provides a simple way to implement cursor sharing in a WebRTC application.
The module is designed to work in conjuction with rtc-quickconnect
sends small (48-bit) payloads of relative
mouse (or touch) changes via a WebRTC data channel to connected peers.
Browser Utility Modules
rtc-captureconfig
The rtc-captureconfig
module is used in rtc
to convert simple string based attributes to valid WebRTC constraints that can be used in for media capture.
Browser Processing Modules
Once you are capturing realtime video and audio in the browser, there is a lot that can be done in terms of video and audio analysis. Listed below are modules that assist doing exactly that:
rtc-videoproc
The video processing module allows you to replace a standard video element with a simulated video element using a HTML5 canvas. This custom canvas provides a video processing pipeline that permits analysis and optional modification of the pixel data that is being drawn to the canvas.
rtc-audioproc
The audio processing module allows you to render a canvas to visualize audio from an audio or video element, or a getUserMedia stream. It uses the Web Audio API. This can be useful to display audio visually, or to track down when a video or audio element does not behave as you expect.
Server Modules
While the clientside modules make up 85% of the rtc.io suite, we do have some server-side node modules that are designed to work with our client side modules when building applications.
rtc-switchboard
This is the server-side companion to the rtc-signaller
module. If you are looking to host a simple in-memory signalling server this is an excellent place to start.
It has been constructed using primus for the websocket communication layer, which means that different node websocket implementations can be used in your applications.
The switchboard can either be incorporated into your node server application code, or hosted separately - whatever best suits your application architecture.


Customization of input html file for Bootstrap Twitter
Project on Github Download Filestyle Production Download Filestyle Development
The Filestyle Bootstrap is a plugin for jquery-based component library could Twitter Bootstrap, used to style the file fields of the forms.
This plugin has an interesting way to present a form for sending files so attractive, while being simple and efficient.
Include the file bootstrap-filestyle.min.js your html code.
<script type="text/javascript" src="js/bootstrap-filestyle.min.js"> </script>
Basic usage:
$(":file").filestyle()
Options usage:
$(":file").filestyle({
textField: "My files",
icon: true
})
Method usage:
$(":file").filestyle("clear")
| buttonText | String | Customization of button text. |
| textField | Bool | Show and hide text field. |
| classButton | String | Use of classes Bootstrap for button. |
| classText | String | Use of classes Bootstrap for text field. |
| icon | Bool | Use icon. |
| classIcon | String | Use of classes Bootstrap for icons. |
| clear | String | Clears a set filestyle. |
License MIT.
Send an e-mail to markusslima@gmail.com


origin : https://forum.solidproject.org/t/conceptual-design-solid-better-user-experience/422/61?u=smag0


I attended PloneConf 2008 recently, to talk about Deliverance. But I’ll talk here more about my observations as a relative outsider to that community. (This post is really written for the Plone community — if you aren’t familiar with Plone this post probably won’t make much sense or be very useful.)
One of the ongoing concerns in the Plone community has been the difficulty of attracting and maintaining developer interest in the community, and generally making Plone easier to work with as a developer. It’s been a very successful community for consulting and integration work, but it has not been as rewarding for developers. There’s the idea of a "Plone Tax", which means different things to different people but just generally speaks to the sense that Plone takes a little off the top — time to restart, time to run the tests, time to dig into code that just goes too deep. There are some distinct problems with Plone, but probably the biggest problem is the quantity of small challenges and the general size and complexity of the system.
At the moment there is no clear path forward to resolve this. A previous effort to fix things is a project called "Five", which referred to Zope 2+3 — backporting libraries and techniques from Zope 3 into Zope 2. Plone is intimately tied to Zope 2, and Five let them use new code without having to do abandon the old environment. But the result wasn’t terribly satisfying: Five didn’t remove any complexity, it only added to it. Even if the new components were superior that doesn’t make them simple. Plone is aching for more simplicity, not more power.
It’s unclear how Plone can actually reform itself as a codebase. Zope 2 is a behemoth, and its metaphors are deeply intertwined with existing code. Acquisition in particular is ubiquitous, essential to lots of the machinery, and deeply confusing. I saw a general interest in two directions: one was to encourage non-content-management tasks to be implemented in a complementary (but separate) technology, another direction is continuing to refactor the existing codebase while somehow trying to maintain backward compatibility.
It’s unclear how to refactor the existing codebase in such a way that it is any simpler, but I suppose these two directions are not exclusive. I want to focus on the idea of a complementary environment. There’s two products in particular that have been attracting interest: Grok and Repoze.
These two products usually go under the umbrella of "exciting new ways to improve the developer experience in Plone" which is a kind of generic positive sentiment. But to my mind they represent two significantly different paths forward, and the differences deserve some more critical thought.
Grok is a layer on top of Zope 3 that attempts to make development in that environment more pleasing. It eliminates most ZCML (ZCML is Zope 3′s XML-based language for declaring the relation of various components in a system). Grok uses conventions and introspection to make Zope 3 look more like a traditional web framework, with simple views and models and templates, and less of the wiring you have to set up in typical Zope 3 architectures. At the same time, you can add all the Zope 3 declarations to break out of the automatic conventions. Grok is a more pleasant layer on top of Zope 3, but it’s entirely focused on Zope 3, and it is led by Martijn Faassen and Philipp von Weitershausen who are both very involved with the Zope 3 community.
Repoze is a more recent project, led by Chris McDonough, Tres Seaver, and Paul Everitt (well, Paul might call himself more of a cheerleader). They all work together at Agendaless Consulting. They’ve been highly involved in Zope 2 for a long time, and are all former employees of Zope Corp and major contributors to Zope 2. I don’t think they’ve ever quite made the jump to Zope 3, and their consulting and experience kept them involved with Zope 2. A while back they got some WSGI religion and started splitting out some pieces of Zope into WSGI middleware and other independent libraries. This included things like pulling out the transaction handler from Zope, reimplementing the Zope 2 publisher so it was more WSGIish, and a variety of other libraries. These libraries are essentially extractions from Zope, or in the case of the Zope publisher and repoze.plone, a way to wrap what would be considered a "legacy" application in the same interface as other newer pieces. Having extracted nearly everything they wanted, they’ve started work on a framework intended to be familiar to the Zope community, repoze.bfg. This framework uses some Zope 3 concepts, but it’s more built from scratch than it is built from Zope 3, and it is attached to Zope 2 only insofar as it uses the pieces they’ve extracted and the ideas they’ve become comfortable with. They’ve described it as the framework they want to use when someone asks them to build something in Zope 2.
Grok and Repoze have a significantly different development methodology. One is a layer on Zope 3, the other is an extraction of ideas from Zope 2 (and a few from Zope 3). In part I think the distinction hasn’t been presented very clearly because the Repoze and Grok communities overlap a great deal, and everyone is quite congenial with each other, and they are reluctant to enter debates about the designs. While I also consider them all colleagues, I also feel pretty strongly about the design differences and I feel a discussion contrasting them is important.
Martijn recently wrote a post on why Plone should consider Grok and a follow-up post. These posts speak to a variety of advantages Grok has over plain Zope 3, which Grok can offer to Plone to manage its existing use of Zope 3 technologies.
I think Plone shouldn’t be so focused on managing the complexity of its stack, but focus on reducing that complexity. And it should reduce that complexity by focusing on content management and moving all the other pieces people have built on Plone out of Plone. It can’t just leave people hanging, which is why developing a clear story for how those other pieces should be developed is essential. Plone the community doesn’t have to map one-to-one to Plone the software. Plone the software should become smaller and more focused. Plone the community doesn’t have to become more focused — the community does what it needs to do, what customers ask for, what is necessary to make a site compelling. To be clear on what I’m proposing here: Plone should have a community-recommended way to build non-Plone applications. This doesn’t mean you have to use those techniques, but it should be much more concrete than just "there’s a bunch of cool things out there, and maybe you should look around and use one of those." By having a community-recommended pattern of development you can maintain and build on the Plone community, which is at least as important an asset as the Plone software.
With this in mind I believe an extraction of Zope 2 and Plone ideas is the right path forward. Extraction is the process of isolating code and ideas, and localizing the effect of that code. These are some of the most important ways to actually increase the simplicity of a codebase. In the Zope 2 (and even 3) codebase the thing that brings the most complexity is the non-locality of code, that parts of the system can effect each other in complex and unexpected ways. Zope 3 formalizes these patterns of non-locality: the Component Architecture is largely about introducing non-localized relationships between code.
Arguably this non-locality of effect is exactly what people want, it’s what enables pervasive customizations. When a client asks you to change some little piece deep in the system, you don’t really want to modify the system’s code — you want to add a little code to the outside of the system that effects the change you desire. The Component Architecture is a formalized way of making these kinds of changes, where Acquisition was a lower-level mechanism to do the same sort of thing. I remain a Component Architecture skeptic, mostly because I think the mechanism is overused. Still I think clearly Plone needs flexibility that a purely bespoke application would not require. But there’s no way out of it: that flexibility has a high cost. In this there is no clear solution. In addition to Acquisition, the complexity of Zope 2 security, the many layers of skinning… is the Component Architecture what Plone needs? From where I stand it seems like a step further in the wrong direction… and yes, it is a better placed step than any of the ones before, but if it’s still a step in the wrong direction does that matter?
I think Plone (at least the community) needs to be conservative in its enabling of these customizations. Sure, the customizability is "powerful," but I don’t hear people clamoring for power. They want simple, predictable, fast, maintainable. That’s not necessarily the same as "easy" — I think sometimes it’s worth making things a little longer and less automatic to make a system more explicit and make code more localized. I think Repoze is a step in this direction, a big (maybe even an intimidatingly giant) step towards simplicity. That’s the step I think Plone should make.
So, I offer this as my suggestion to Plone. I think Plone-the-community has the opportunity to be more than Plone-the-software; I think it must do this to remain viable in the long term. But to get there the community make some choices — you can’t add simplicity.
No related posts.
Concerning Repoze “versus” Grok. Yes, there are differences: Repoze does a lot of rewriting in the interests of implementation simplicity. Grok hasn’t rewritten the implementation and focused on usage simplicity. The two systems are learning from each other: Repoze can use bits of Grok’s auto-configuration system. Meanwhile inspired by some of Repoze’s work (as well as frustrations with some of Zope 3′s non-locality), I’ve started looking at simplifying parts of the underlying Zope 3 system (and in general the sometimes complex structure of dependencies in the Zope 3 codebase is a thing Zope 3 developers are concerned about).
Grok’s busy extracting useful bits of code from itself and both Martian as well as grokcore.component are reusable in random Python projects. The rest of the grokcore.* stuff is reusable in Zope 2 and in fact reuse in Zope 2 is driving this process.
You say the use of the component architecture is a step in the wrong direction, but could you be more explicit about why this would be so? What if you use it in moderation? Some form of customization machinery is needed and sticking to the (well-engineered, much used, battle-tested) devil we know seems like the right idea to me.
It’s important for any scenario to move forward is to have a way to evolve from A to B. You can take risks in this evolution, and perhaps larger risks should be taken, but it still will have to be an evolutionary step.
The word “simple” means different things to people. Simple in implementation? Simple in use? Simple to change? Assembly language is simple in implementation and Python adds huge amounts of abstraction and automation over a machine. Yet, Python’s a lot simpler in use than assembly language, even though assembly is so much simpler in implementation. So, of course automation and abstraction can be added to a system to make things simpler! That said, implementation simplicity can increase usage simplicity as a system can become easier to understand and predict, but it’s hardly clear-cut. Simplicity in implementation is valuable when it increases simplicity of development, and simplicity of use.
So, I’ll grant there is value in simplicity in implementation. I also believe Plone’s implementation can be significantly simpler. It’ll still be complex no matter what, though, just less complex than it is now. Any move to simplify Plone will run the risk of trading off one form of complexity for another. There is also value in sticking to the complexity the community knows about.
I believe Plone’s best road to simplification takes two paths:
Towards simplicity of implementation: removing some of the old ways of doing things permanently. Hopefully a point in evolution has been reached that old things can be removed. The removal of acquisition from the system would be a good, though big example. Allow content types that are truly simple and don’t rely on SimpleItem and a whole bunch of other things would be another good step.
Towards simplicity of use: adding easier ways to do things that are too hard right now. Using Grok technology to help with the wiring of the inevitable configuration machinery is a good example.
The alternative would be writing a new CMS taking into account the lessons learned from Plone. That’s an interesting project. Is it the Plone project?
One other road to take if simplification of Plone is not that easy, is to simplify the use of Plone the software for other Python developers not willing to pay the Plone tax. Using ContentMirror, for example, it is possible to serialize Plone content into a relational database and create simple applications on top of that using any other framework.
Granted, this is not an approach that can be used for all kinds of projects, but there are many use cases where separating the content production from its delivery would be a very good idea. Plone is a very good CMS, so I think it would be great if people not willing to use it as a framework can still benefit from it as a piece of software. That would make Plone, the community, even bigger.
In part, this comes down to the old “application vs. platform” argument. I think that technologies like WSGI and Repoze are enabling Plone to be more of an application again, because, as you say, non-CMS functionality can be built elsewhere.
I personally believe that Repoze and Grok are both key to Plone’s future. Roughly, I think the roadmap should look something like this:
Rip out things we no longer need (already happening on trunk).
Where two ways exist to do something, choose one way and remove all other ways (starting to happen on trunk).
Target key use cases for extending Plone-the-application and focus on making these as easy and friendly for integrators as possible (this is where I think Grok conventions and patterns will be beneficial). This includes things like:
Push services that could cross-cut applications out into WSGI middleware so that they become reusable (this is where Repoze comes in)
Promote the use of other, WSGI-enabled frameworks for non-CMS tasks (be that repoze.bfg or Grok or something else)
Promote a way to unify look-and-feel/theming (this is what Deliverance promises).
I whole-heartedly agree with Martijn’s point about evolution. Developers have a strong tendency to favour a rewrite or a clean break, but that’s a sure way to lose those who’ve already invested in the platform. We’re only just now coming to the point where the feature set and the available tools and frameworks cover what I’d consider the basic CMS needs (with a few exceptions), and there’s a real drive in the community now to focus on simplification and the integrator experience.
At the same time, we need to be very careful about throwing the baby out with the bathwater. The Zope 3 CA has an important part to play in making Plone a productive, usable and flexible system. People may not be clamoring for more power, because they have power now. We’d like to unify the way in which that power is provided (e.g. by removing some things that still rely on acquisition when it should rely on components), not take it away.
We also need to be better at indicating what extension points and APIs are aimed at integrators/developers and what things are really just the concern of Plone’s core developers. Right now, “the API” is kind of the whole application, in that you can customise and change anywhere. We need to ring-fence that with something a bit more obvious that gets people started quickly, and only require them to get into that level of detail if they really need to.
Cheers,
Martin
I think Plone should take a carrot approach to simplification, not the stick of removing or deprecating techniques. Right now every Plone site of any substantial size has non-CMS aspects to it. Removing things from Plone is politically difficult as a result. Getting people to implement those non-CMS things outside of Plone seems like the easier approach at the moment, the approach that is on most people’s timelines (even if the dates are different), and it doesn’t have to effect backward compatibility right now. But actually doing this isn’t easy, and probably requires some extra help from Plone as well. So I think it makes sense to figure out that story, to focus on that work for now, because it’s not a small amount of work and it won’t happen with out direct effort. If that’s successful then I think it’ll be much less disruptive if Plone itself is simplified.
As Carlos suggests, I think ContentMirror could be part of that story. The more formally “correct” solution might be web services of some sort, but I think a relational database mirror is probably better understood and less likely to cause performance problems due to its implicitly async design.
+1 on contentmirror, the concept seems great and I’m looking forward to trying it.
In my experience with the use of components and component adaptation in Plone, there are two major problems.
The first is, that adaptation is overused. A portlet is a five-way adapter and there’s no way to change the adaptation order. This rules out a swift solution for most of the more advanced use-cases, simply because you’d have to work very hard with the system to get the adaptation pattern you really want. Adaptation as we know it is simply not a very good multiplexer.
The second issue is that we can’t really ever strike the right balance between explosion and coherence in defining the scope of a component. The best example I know of this is the navigation machinery. This is implemented as a collection of components that each have some scope and function and they’re glued together using the component registry. However, in most cases, I’ve wanted to simply provide a replacement wholesale, and in this case, the exploded code chain is counterproductive and needlessly complex.
To recap, I believe the correct usage of components is to adapt on small specifications, with one-way or two-way being standard, avoid adaptation for multiplexing where possible and finally to avoid exploding our software into too many components. We still have object-oriented programming and Python is still a dynamic language.
It’s pretty hard to do the matrix calculus that makes most of the various Plone constituencies happy while still doing something useful along any meaningful simplification axis. So finding some middle ground where Plone stakes out its ground as-is (“CMS”), and other tasks are delegated to other systems as necessary is probably a good idea.
But at the same time, I’d probably avoid taking this route for new customer projects. Content management features aren’t too hard to create in any of the new crops of Python web frameworks. Writing a form, even auto-generating that form using some framework, accepting input from users, showing errors, managing users, etc: for any given project, satisfying these types of requirements tends to be pretty easy without Plone. It’s often much harder to remove unnecessary features from Plone than it is to create the necessary ones from scratch. It would take a heck of a lot of intersection between a random customer’s requirements and the feature set that Plone provides out of the box for me to use Plone as the “CMS”, and delegate other tasks to a simpler system. I’d tend to just use the simpler system for everything, left to my own devices. That said, for legacy systems that already use Plone, I’d likely go with Content Mirror.
IMO, the killer feature of Plone that no other “framework” has is that it does something out of the box. Folks who install and use it can quickly get a frame of reference quickly, and they can describe (to themselves or others) requirements in terms of modifications to that out of the box experience. And for better or worse, people tend to do those modifications to Plone to satisfy the requirements. So it drives a good deal of consulting business.
So how do we square the circle? I’m not sure. But I don’t think too many tears would be shed if something else were created that was materially simpler and offered some similar set of features out of the box. I suspect that a phoenix-from-the-flames project that aimed to recreate a Plone-ish out-of-the-box experience, but which ditched backwards compatibility would probably be most successful in the long run. There are of course Plone add-ons and such, and these are important, but even without those, an alternative could probably support a healthy community. It shouldn’t be called Plone, obviously. This of course mirrors what we’re doing with bfg vs. Zope, so I suppose my saying any of that is not very surprising.
Obviously one of the biggest issues is a political one. Sure, other people can write a CMS. Someone could even pay a lot of attention to migration, and maybe pick out a handful of the most popular add-ons to also translate, and so make the intention as a successor clear. But that itself doesn’t make a New Plone.
At some future date I think the community could choose to make a radical change like that — and even call the result “Plone” — but it will be easy only if Plone is a CMS and not a platform for building entire web sites. Which is why I suggest this path to making Plone into more of a CMS and less of a platform. And ultimately that question of how to make a complete website must be answered — another part of Plone’s success is that it answers that question. So right now recreating just the CMS of Plone wouldn’t be sufficient to really recreate Plone.


What is the Caesar Cipher?
Who is the cool guy that made this page?
How to Encrypt
- Pick a plain text message you want to encrypt
- Select a cipher value
- Select Encrypt
- Click Go
- Your Encrypted message will appear in the section below the form
How to Decrypt
- Paste your decrypted message in the text area
- Select the cipher value used to encrypt the message
- Select Decrypt
- Click Go
- Your Decrypted message will appear in the section below the form