I did some serious reading and thinking about how I might be able to help a startup stay out of crunch mode, and came up with the following recommendations.
Getting out of crunch mode is a challenging transformation, because it requires changing a company's culture, business plan, and software development process, and these things are hard to change.
It is a matter of changing the company's culture. This has to start with the founders. You have to value a work-life balance. One pointed way I saw this put was: you have to value your employees' bodies more than your profit. Benefits: 40 hour weeks improve employees' happiness and productivity, and enable the company to hire from a broader pool, including hiring not ONLY junior employees who are smart, productive, ambitious, and perhaps naive about the "churn and burn" process at some startups, but ALSO more senior employees who are domain experts (think Ph.D.s), stable, reliable professionals, and seek a better work-life balance out of wisdom and not merely necessity. You plan to expand your development team, and a broader candidate pool would make it easier to find candidates willing to relocate to [your non-Silicon Valley location].
It is a matter of changing your business plan. The release deadline pressure comes from selling what you don't have. You can transition to selling the features you have, and selling development services. This can be done gradually, and to a greater or lesser extent. Benefits: This reduces deadline pressure. Selling existing features to new customers also increases and diversifies your customer base, and you can leverage this portion of profit to fund new features. You can still contract to create new features for clients, but rather than guaranteeing specific features as the primary deliverables, guarantee your development services for a period of time as the primary deliverable, delivering new features frequently in an agile manner. This is a paradigm shift which could seem impossible to implement because some clients require feature deadlines, but for some clients faster iteration and constant feedback loops actually give them more needed features faster than they would get under feature deadlines.
It is a matter of changing the software development process and feature delivery architecture you use to implement your business plan. You can use branch-by-abstraction, put unfinished features (or alternative/optional/sales-tiered finished features) behind feature flags, implement continuous integration and continuous delivery, and so move to more frequent releases and a rolling release cycle. Continuous delivery and frequent releases are harder with software as complex as operating systems, but still possible. Benefits: Faster development velocity, shorter time-to-market for new features, so quicker response to competition, and less pressure on release day, because every day is a release day in that stable release candidates are built every day. Some companies say they could not compete in today's market without using continuous delivery.
2. Surprisingly, Henry Ford found reducing from 6 to 5 10-hour days actually made his workers produce more per week, and a further reduction to 5 8-hour days brought a further increase in production. This was with assembly line workers; arguably knowledge workers' productivity increases similarly when they are not tired. This and much other related research is mentioned in the paper responding to crunch mode at Electronic Arts at http://cs.stanford.edu/people/eroberts/cs181/projects/2004-05/crunchmode/index.html. This paper is the best collection of material I found which makes the point that it's best to avoid crunch mode. http://www.igda.org/?page=crunchsixlessons is a good presentation, too.
A friend shared some experiences and asked me effectively,
"How should individual Christians give handouts to the needy?"
I'm thinking about what to say in response to your questions. Lots of thoughts come to mind. Here are some of them:
1. God freely justifies, so we should freely give the first time someone asks. God also sanctifies, so we should only continue helping if the needy person is willing to obey God's commands, and work to get the help they need. You have to be willing to say things like, "This is a free gift because God forgives those who repent of their sins and believe in Christ, free of charge," and "Friend, until you put in that job application I helped you get and you promised you'd fill out, I'm not going to help you further." Sometimes how they respond to such requirements will show you their true colors.
2. Don't give money to needy people; give food, clothing, buy their bus ticket. So many spend the money on drugs, alcohol, cigarettes. If they want gas for a long trip, consider taking them by the police station first to be sure they're not on the run. If they're going on a long trip, they have the time.
3. Ask, "Do you go to a church?" If they say "Yes," ask which one, and send (or offer to take) them there (say "I'll help you, through your church.") If they say "No," ask "Why not?"
4. Instead of handouts, give money to your local church first, then a homeless shelter or some other such organization which is well-equipped to help, and is integrated into that locale. They have the ability to hold people accountable to change their lives, by the strength God provides through the gospel and practical counseling. Tell the needy, "I give through my church (or X homeless shelter). Come there with me and we'll help you out. On the way, let me tell you what God has done for me. Have you ever committed a sin?" Are you going to lead them, or are they going to lead you?
5. Bankrupt people can't keep all their promises, however sincere they are. They can't. They don't have the resources.
6. I'd hardly trust anything or anyone in Las Vegas. I don't have to tell you that, but maybe it bears repeating. I want to believe needy people's stories, and in a sense I do (I take them at their word), but I don't trust anything a needy person says. I trust solid evidence from two or more independent sources.
Also regarding Las Vegas, I don't think it's right to replace 1) gambling with money with 2) buying needy people's ears for the gospel with money. This is a subtle matter of priorities in your own heart, which may not actually change what you do on the outside. We should want to help people with money, and their greater need is for the gospel. Our intent should never be to bait and switch, but to address the person's true needs as a whole. There is a temptation in which needy people place me and other Christians, to substitute diaconal aid for gospel ministry. A needy person's request is an opportunity to share the word, as well as to help that person.
7. Whenever I pray with a needy person, I ask God to forgive their and my sins for Christ's sake, and to help us follow Christ as our Savior and Lord, for our good.
A friend asked me how I reconcile the Bible’s apparent teaching that the universe is young with star light’s indication that the universe may be very old. We understand that stars are millions or billions of light-years away from us. I replied as follows with the resources I have.
You might find the following article interesting in connection with considering the age of the universe.
"God made (not created) the expanse (v. 7a). From what did He make it? The form ‘expanse of the heavens’ may indicate the ‘what’, for it is used four times (vv. 14, 15, 17, 20) even after God called it ‘heavens’. Thus, ‘expanse of the heavens’ suggests ‘the expanded form of the (original) heavens’. That sounds like God started with the original heavens of v. 1—the substance or fabric from which to make finished heavens—and expanded or stretched them out to make places for the luminaries (space).
Thus, ‘the expanse of the heavens’ seems to be the stretched-out form of the original heavens. Confirmations are found in Scriptures written later, if stretching is identified with expanding. Job 9:8, Is. 40:22, Is. 51:13, Jer. 10:12b=51:15b, Zech. 12:1, ‘Who/He (alone) stretches (-ed) out the heavens’. Is. 42:5, He ‘created the heavens and stretched them out’ (created and made). Is 42:12, Is. 48:13, add the anthropomorphism: ‘...with His hands/My right hand...’. Ps. 104:2b, ‘stretching out the heavens like a tent curtain’. Some take such stretching as metaphorical, but equating ‘expanding’ with ‘stretching’ obviates any reason to do so and makes good sense."
My basic thought which might be useful to you is this: if God stretched out space, He may well have stretched out the star light within that space at the same time, ending with his fixing the locations of the stars (and so ceasing His work of stretching out the "expanse"?) on day 4. I don't think this provides a comprehensive answer to your question, but I find it satisfies my curiosity sufficiently, and on biblical grounds. The article's authors think in a similar way in regard to day 2, before the stars were made:
"God’s separating the matter droplets so far from each other caused their light to dim or go out temporarily, for a second night time. It also stretched out the first light in the universe, resulting in low-frequency background radiation. Hence, this second night was not utterly devoid of light, as was the first, but it was relatively dark as ours are now." (p. 74)
"The physical concept just described includes all these smaller blobs forming their own gravity wells then being separated from each other by expanses governed by gravity. There are 13 references in the remainder of the bible confirming that God stretched (Job 9:8, Psa.104:2, Isa.40:22, 42:5, 44:24, 45:12, 51:13, Jer.10:12, 51:15, Zec.12:1) the heavens or spread out (Job 26:7, 37:18, Isa.48:13) the heavens and/or the earth . The stretching implies the expanding of the gravitational fields between the masses (blobs) as they are spread throughout the universe."
"The setting of the luminaries could explicitly refer to the positioning (including relativity and time dilation) of all the heavenly objects in their time and space and limiting their movement with respect to Earth. Most likely it also refers to the stopping of the stretching. Job 37:18 in the NIV translation captures both these concepts in one verse. Other references in the Bible confirm God's act of setting the luminaries in their locations in the sky (e.g. Psa.8:3, 148:6, Pro. 3:19, 8:27, Isa.51:16)."
Russell Humphreys wrote the following book which seeks to directly answer your question:
Humphreys, D.R., Starlight and Time: Solving the Puzzle of Distant Starlight in a Young Universe, Master Books, Colorado Springs, CO, p. 53, 1994.
DeRemer, Dobberpuhl, and Amunrud replied to Russel Humphreys' response to their article at https://creation.com/images/pdfs/tj/j22_1/j22_1_56-58.pdf. Humphreys advocated the view that time dilation is the explanation for light coming from distant stars in a young universe - that is, "young" from the perspective of earth, because according to the theory of time dilation, time has not moved at the same rate from the perspective of every location in the universe. So far as I have read, it appears to me that the primary evidence for the theory of time dilation has been given a much simpler explanation, leaving the theory of time dilation without convincing evidence (see https://en.wikipedia.org/wiki/Russell_Humphreys#New_Cosmology; https://en.wikipedia.org/wiki/Pioneer_anomaly). Nevertheless, you may find Humphrey's book useful, because it attempts to directly answer your question.
This appears to be an attempt at a serious critique of Humphreys' theory: Conner, Samuel R., and Don N. Page. “Starlight and Time Is the Big Bang.” CEN Tech. J 12, no. 2 (1998): 174ø e194. Available at http://www.trueorigin.org/rh_connpage1.pdf.
Personally, I am inclined, because of scripture's statements that God "spread out" the "expanse" (which can mean something which has formerly undergone an action of being spread out; the article by DeRemer, et. al. led me to see this as significant), to think that God may have created each star's light on day 2, while He also was--as an act of extraordinary (not ordinary) providence--greatly expanding the universe, which would be a reason to consider that the stars' light may have traveled "faster" or "further" in proportion to the size of the universe than it does today, and if that is not the correct or full explanation, I am inclined to think that God could have created not only each star, but also the full extent of each star's light, on day 4, and it is possible God caused that light to travel "faster" or "further" on day 4 by an act of His extraordinary providence.
I'm reposting here an
I wrote since it was well-received on the CouchDB marketing list, but its formatting did not display well there.
One of CouchDB's developers asked,
How can we make it that CouchApps strengthen CouchDB and not weaken it by adding confusion?
How do CouchApps fit into the CouchDB story?
I've been thinking about this discussion a little, and wanted to offer a few ideas from the perspective of a user. In essence, I think the CouchDB community should focus on marketing two concepts named "CouchDB," and "Couch App Server." This is a middle ground between the two extremes of "R.I.P. CouchApps" and "CouchApps are CouchDB's greatest feature!" The middle ground is achieved by distinguishing CouchDB and CouchApps, and marketing them as two distinct ideas. You don't have to stop marketing the idea of CouchApps; just market them as something distinct from CouchDB. Both can be positively marketed, and succeed or fail on their own merits. But by distinguishing the two, if CouchApps confuse people, they need not turn people away from CouchDB. My thoughts and reasons for this are below.
1. Evaluate the current marketing. CouchApps are mentioned front and center in the first two paragraphs about CouchDB at http://couchdb.apache.org/. They are mentioned in concept, though not by name. They are implied in the slogan, "A Database for the Web" which is explained by those two paragraphs. If CouchDB's marketing should take a different direction in the future, that marketing ought to deal with the question of whether the promises made in those two paragraphs are true. Specifically, "CouchDB comes with a suite of features, such as on-the-fly document transformation and real-time change notifications, that makes web app development a breeze." Does CouchDB "make web app development a breeze," or not? These two paragraphs are the first ones to change.
2. Make CouchApps secure. If multiuser data within CouchApps cannot be properly secured presently because CouchDB does not require clients to send the Host header (I tried to test whether this is the case per this email), then make a config option to make CouchDB require the Host header. It sounds easy to do, and the Host header is required in HTTP 1.1. Or create a "default _rewrite path" configuration parameter as Giovanni described. I expect this would make SmileUpps' CouchApp architecture secure for anyone who wants to use that architecture.
3. Don't promise CouchApps are easy. SmileUpps' CouchApp architecture is the only CouchApp architecture I'm aware of which has (almost) implemented document-level ACLs without some proxy server between the browser and CouchDB. Others may exist; I just don't know about or remember them. I have 15 years of part-time experience in full-stack web development, and have written two small CouchApps. It doesn't appear to me that SmileUpps' CouchApp architecture is particularly easy for novices to learn and implement, at least at present. Perhaps with a Yeoman generator or the like it could become easy. But its current complexity does not seem to me to "make web app development a breeze," that is, if you want to prevent some users from reading all the data in one database, which is a normal or at least common requirement in web development. The end result is not good--CouchDB's promise of easy CouchApps will lead novices to build insecure apps. I wish CouchApps did make web app development a breeze, and would like to see CouchDB still be able to use that promise in its marketing. But for now, it seems to me that CouchApps shouldn't be marketed to novice developers as an easy point of entry into web development. CouchApps are rather a way for developers who already know (one of the many ways) how to structure a single-page app to serve that app out of CouchDB, and access CouchDB as the app's database. It seems to me a developer should learn Backbone or Angular before CouchApps (like the Chatty tutorial assumes: https://www.smileupps.com/couchapp-tutorial-chatty-read-api). So, because they generally require 1) knowledge of a client-side framework, 2) knowledge of CouchApps' file structure and functionality, and 3) implementing a very specific CouchApp configuration to be properly secured, CouchApps aren't really an entry point into web development. Instead, CouchApps are a way for non-novice developers to use CouchDB as both a database and an app server.
4. CouchApps could rise again! CouchApps' prospect of master-master replication of not only data, but apps, remains attractive to me. Give users their data, and give them their code! It's a powerful thing. What if we all owned Facebook running in PouchDB in our browsers, without a persistent central server? Diaspora, CouchAppSpora/Monocles, and a bunch of other software have aimed in this direction. So I don't think it's wise to pull back completely from marketing CouchDB's CouchApp features. Perhaps they could still be the future.
5. Reprioritize marketing to serve today's web. "CouchDB is [still] a database that completely embraces the web." But the web has changed since CouchDB first embraced it. Web apps have moved toward offline-first and syncing data to the server via REST. Web apps don't live on the server anymore. They live in your phone. So, as an app developer, I don't need routing or SEF URLs (vhosts/rewrites) on the server; I need routing in the client. While I still want to be able to query a CouchDB view via HTTP, or maybe even a show or list on occasion to provide an RSS feed, more often I want to query my data locally in PouchDB or something like it. So it doesn't make sense to me to prominently market CouchDB's "on-the-fly document transformation" anymore. I still want the feature, but it's not in the core of what I need. What I need is a database that syncs. CouchDB's other application server features are nice when I want them.
6. Market an accurate Venn diagram. The relationship between CouchDB's CouchApp features and CouchDB's non-CouchApp features is not one where you can divide the features neatly into two mutually-exclusive sets. Rather, CouchApps use nearly all of CouchDB's features (except maybe replication), and non-CouchApps use a subset of CouchDB's features. CouchApps may or may not use replication depending on whether they use something like PouchDB, and whether they use replication for deployment. To put it in terms of my main proposal, future "CouchDB" would be a subset of CouchDB's current features, and "Couch App Server" would be a superset of that future "CouchDB" set. This makes me think that it is hard for people to grasp what it means to disable the features which support CouchApps, because they too easily believe this means disabling the superset; disabling the whole of CouchDB 1.x's features. So I think the best way to explain this to new users is to say that CouchDB is a database, and it comes with some extra features which are useful for an application server. The first two paragraphs at http://couchdb.apache.org/ say as much, but they do not distinguish these two concepts in a way that is obvious and memorable to a newcomer, or that would convince the newcomer that they might want to use CouchDB as a database alone apart from its additional application server features. The newcomer is left with the impression that the features unique to "Couch App Server" are actually part of the database, but while they are part of CouchDB, yet they are not technically database features; instead, they are web file server and document transformation features.
The way I perceive the natural groupings of CouchDB's features is as follows:
i) Database: The database that syncs (views (=indexes), HTTP interface, replication, filters, MVCC, changes feed, authentication) ii) [App Server?]: Web file server (vhosts, rewrites, attachments) & design docs/stored procedures for further document transformation (views, shows, lists, update handlers)
i) is the core set of features, and i) + ii) = CouchApps. I think this distinction should be displayed textually and graphically on CouchDB's front page.
Interestingly, ii) contains features of the past (server-side apps) and the (maybe) future (client-side apps, deployed through replication). It would be worth noting this distinction on CouchDB's front page to help newcomers decide to what extent they need Couch's app server features. It remains possible that someday the present swing toward client-side apps will reverse, and even these server-side features could become more of the future. So I don't think the marketing should characterize CouchApps as a dying remnant from the past which will not be relevant in the future.
Earlier in CouchDB's lifetime we thought CouchApps using all of ii) were the future. Now because there is less need for server-side routing and document transformation, the main parts of ii) which might be the future are views (for occasional direct queries over HTTP - yes, I included views in both i & ii), attachments (for serving/replicating your app's files from the database), and lists (for RSS feeds or data syndication/federation through filtered replication). But it would be good to say on CouchDB's front page that a developer might not need any of the features in ii) today.
So Couch's app server features should not be marketed as extra features for advanced users. They don't add functionality which every developer will want after they master the basics. Rather, they are extra features which permit you to write limited server-side logic for your application, if you find you need it. This is actually a useful point for a newcomer, because while single page applications running in the browser can perform most of the logic we need today, yet (aside from issues of data security and proprietary code, which are the realm of server-side node changes listeners) due to reasons of architecture and efficiency, we are not able to run all our logic in the browser; it's still wise to keep some logic in the database on the server side. Often we're still dependent on server-side logic, and Couch's app server features can meet that need to a limited extent.
One result of the features in ii) is that your app's server-side and client-side logic can be synced from one server (CouchDB instance) to another. For example, from your local development machine to the deployment server, or from one deployed application instance to several other nodes all running the same application, but with different filtered sets of data. This warrants the slogan, "Apps that sync!" However, that slogan might make people think the syncing in view is between CouchDB and the web browser, which is not what I mean by the slogan. The apps' syncing is actually done by the features under i), but they are apps because of the features under ii). So the "Apps that sync" do so because they are in "The database that syncs."
7. My proposal. So I propose splitting the features described in the first two paragraphs at http://couchdb.apache.org/, features which are mixed together there under the one name of "CouchDB" without any clear distinction, into two sets of features under two separate names and slogans:
1. "CouchDB" - the database that syncs! 2. "Couch App Server" - apps that sync!
Since I (as an app developer) only need CouchDB, market CouchDB most prominently. But since Couch App Server is nice when I want it, and might be a good method for deploying app updates, market it as a nice but limited set of server-side features your app can use (even to serve your app), which can be secured, and which can be used to deploy app updates, but which you probably don't need if you are using a modern client-side application architecture. If people want server-side features, this will be a selling point. If people don't want server-side features, they will appreciate being told that they don't need to research CouchApps.
Because I want Couch App Server's features sometimes (RSS feeds), I think they should be enabled by default. I don't see why it would be necessary to provide a configuration option to turn them off, but I wouldn't mind if they were turned off.
Though a graphic designer could figure out a better way than this, I envision presenting this distinction between "CouchDB" and "Couch App Server" in a graphic which shows CouchDB as the fundamental layer of Couch's architecture, and Couch App Server as an optional layer on top of CouchDB which includes additional features. Below the graphic, I envision two columns of text, with CouchDB's description on the left, and Couch App Server's description on the right, and somehow CouchDB being portrayed as the most important of the two. If you want to hide Couch App Server on the front page, then present only CouchDB on the front page, and provide a link to a page describing "Additional features" which presents the two-layer graphic and two-column descriptions I mentioned above.
If you want to remove the word "Couch" from "Couch App Server," just call it the "App Server." That was easy. : )
The OPC Form of
Government 23.11 requires after the installation of a pastor, “Solemn
charges in the name of God shall then be given to the newly installed
pastor and to the people, to persevere in the discharge of their
mutual duties, and they shall both, by prayer, be commended to the
grace of God and his holy keeping.”
As I considered what charge to give to the newly-installed pastor
and elders, men with great gifts and manifest godliness, I had to
ask, “Who am I to give this charge?” I have little to offer
you—except by ministering God’s word, in which is found the
riches of salvation in Jesus Christ. After all, this must be not
only my method, but also yours.
Minister God’s word, and you are rich. Minister yourselves, and
you are poor. But by standing on the word of God you will be
in the scriptures” (Acts
portions of God’s word would be appropriate for this charge:
Ezekiel 34’s exhortation to love, lead, feed, heal, correct and
restore God’s sheep, or Paul’s farewell address to the
Ephesian elders in Acts 20, calling you to “Pay
careful attention to yourselves and to all the flock, in which the
Holy Spirit has made you overseers, to care for the church of God,
which he obtained with his own blood” (Acts
20:28). Peter’s exhortations for elders to be
humble, gentle, self-sacrificial shepherds and overseers would
also be wholly appropriate. And in fact “All
scripture is...useful for teaching, reproof, correction, and
training in righteousness, that the man of God may be fully
equipped for every good work” (2
Tim. 3:16, 17). But as I considered that Paul’s
exhortation to the Ephesian elders forms the seed which came into
full bloom in Paul’s later letters to Timothy who was the
Ephesians’ pastor, it became clear which passage I should
to you the books of 1 & 2 Timothy. Paul’s letters to the
Thessalonians are intended to teach a congregation how to receive
the ministry of a pastor; Paul’s letters to Timothy are intended
to teach a pastor and elders how to minister to a congregation.
Make use of these books to guide you as you begin and continue
ministering in this congregation. Let them guide and correct you,
encourage you in God’s blessings on your work and warn you of
the destructive power of men’s sin. Turn to 1 Timothy for the
foundations of your ministry. Turn to 2
Timothy for the revival of your ministry.
Tonight is the night, and this year is the year, to lay the
foundations of your ministry, so let us
give attention only to 1 Timothy tonight.
teaches you have a charge to minister the
gospel of Christ, “that
Christ Jesus came into the world to save sinners”
(1 Tim. 1:15). “The
law is good, if one uses it lawfully....in accordance with the
glorious gospel” (1 Tim.
1:8, 11). Paul says, “This
charge I entrust to you” (1
Tim. 1:18). Use the law to correct men’s sin, the
gospel to save them from sin, to achieve “the
aim of our charge...love that issues from a pure heart and a good
conscience and a sincere faith” (1
teaches that “therefore”
(1 Tim. 2:1) you
must lead God’s people in prayer—prayer for all men, for
their peace and salvation, “for
there is one mediator between God and men, the man Christ Jesus,
who gave himself as a ransom for all” (1
Tim. 2:5, 6). How will men be saved unless you lead
them in prayer?
teaches you must train up, evaluate, and ordain
new elders and deacons, that the church will continue to serve
pillar and buttress of truth” in society (1
Tim. 3:15). In practical terms, God’s word in elders
is the “pillar,”
God’s deeds in deacons is the “buttress,”
of the truth of the gospel in the church and this world. Do you
want this church to have a solid structure built on the foundation
of Jesus Christ? Do you want it to defeat the kingdom of darkness
in this place? Then you must raise up officers. You must raise up
new officers, however long that takes.
teaches you must wage war against false
doctrine and practice. You are an officer in a war. A lethal
threat comes from apostates (vv. 1-5),
but you must gain victory over it in yourself (vv.
6-10), and in those whom you must “Command
and teach these things” (v.
11). Train yourself “in
the words of the faith and of the good doctrine that you have
followed....train yourself for godliness” (vv.
6, 7). “Let
no one despise you for your youth, but set the believers an example
in speech, in conduct, in love, in faith, in purity....devote
yourself to the public reading of Scripture, to exhortation, to
teaching” (vv. 12, 13).
in this, for by so doing you will save both yourself and your
hearers” (v. 16).
teaches you must build
the bonds of love in the church. Encourage and honor each
member according to their station and place in life. “Do
not rebuke an older man but encourage him as you would a father.
Treat younger men like brothers, older women like mothers, younger
women like sisters, in all purity” (vv.
1, 2). Take a special concern for the care of widows
and the honor of elders.
teaches you must be faithful to the end - until Christ comes.
Your greatest and final inheritance is not in this world, but in Him. “Flee”
love of money” to the “great
gain in godliness with contentment” (vv.
Pursue righteousness, godliness, faith, love, steadfastness,
gentleness. 12 Fight the good fight of the faith. Take hold of the
eternal life to which you were called and about which you made the
good confession in the presence of many witnesses. 13 I charge you
in the presence of God, who gives life to all things, and of Christ
Jesus, who in his testimony before Pontius Pilate made the good
confession, 14 to keep the commandment unstained and free from
reproach until the appearing of our Lord Jesus Christ, 15 which he
will display at the proper time- he who is the blessed and only
Sovereign, the King of kings and Lord of lords, 16 who alone has
immortality, who dwells in unapproachable light, whom no one has
ever seen or can see. To him be honor and eternal dominion. Amen.”
now I commend you to God and to the word of his grace, which is able
to build you up and to give you the inheritance among all those who
are sanctified” (Acts